OldUnreal (Engine)

By the way another issue I have is that I'm getting kicked from servers regarding illegal renderer. Any idea if that's gonna be fixed in the future?

This is something which I can't influence from here, it's common to deny every unknown renderer to avoid possible cheating, since it's a good place to hide bot's or other hacks in. Those servers (or rather the admins of them) need to whitelist this renderer (and every following update then) for that. Hard to say if XOpenGL will become popular enough to be whitelisted in general in the UT community some day.

About the particular problem of overall awareness and distribution of renderers and other similar things, I am actually currently pretty much working towards creating a solution for that.

I made a post with my plans at ut99.org for the future concerning both UT99 and Unreal: https://ut99.org/viewtopic.php?f=12&t=12684

It's a long term project, and I am still at the very beginning, so it's very early to say if something like this will really succeed or not, but for what it is worth, I do intend at the end of this to be able to provide a way to actually make the hard work of everyone to actually get known and used, and get used easily, such as having this renderer used and whitelisted in most servers at the very least, even upon updates.

It will take a long time to get there though, but I have been working on it pretty much everyday to try to make it happen, so only time will tell.


EDIT: Well, it seems that the current XOpenGL versions will be officially whitelisted, given that anth just posted this:
https://ut99.org/viewtopic.php?f=33&t=1 ... 54#p104754
So I guess this will no longer be a problem in the short term, nice.

By the way another issue I have is that I'm getting kicked from servers regarding illegal renderer. Any idea if that's gonna be fixed in the future?

This is something which I can't influence from here, it's common to deny every unknown renderer to avoid possible cheating, since it's a good place to hide bot's or other hacks in. Those servers (or rather the admins of them) need to whitelist this renderer (and every following update then) for that. Hard to say if XOpenGL will become popular enough to be whitelisted in general in the UT community some day.

Got it. Hopefully it will! Thanks man.

By the way another issue I have is that I'm getting kicked from servers regarding illegal renderer. Any idea if that's gonna be fixed in the future?

This is something which I can't influence from here, it's common to deny every unknown renderer to avoid possible cheating, since it's a good place to hide bot's or other hacks in. Those servers (or rather the admins of them) need to whitelist this renderer (and every following update then) for that. Hard to say if XOpenGL will become popular enough to be whitelisted in general in the UT community some day.

About the particular problem of overall awareness and distribution of renderers and other similar things, I am actually currently pretty much working towards creating a solution for that.

I made a post with my plans at ut99.org for the future concerning both UT99 and Unreal: https://ut99.org/viewtopic.php?f=12&t=12684

It's a long term project, and I am still at the very beginning, so it's very early to say if something like this will really succeed or not, but for what it is worth, I do intend at the end of this to be able to provide a way to actually make the hard work of everyone to actually get known and used, and get used easily, such as having this renderer used and whitelisted in most servers at the very least, even upon updates.

It will take a long time to get there though, but I have been working on it pretty much everyday to try to make it happen, so only time will tell.


EDIT: Well, it seems that the current XOpenGL versions will be officially whitelisted, given that anth just posted this:
https://ut99.org/viewtopic.php?f=33&t=1 ... 54#p104754
So I guess this will no longer be a problem in the short term, nice.

Wow that's amazing man! Thanks a lot for all your hard work! Every old school UT99 player like myself appreciates it a ton

Hoping someone might be able to help me. I installed XOpenGL v1.0.0.9 (along with OpenAL v2.4.7, but I don't think this was the issue) and now Unreal Gold crashes instantly before startup.

Error message (red X):
Unreal (Starting): Unreal.exe - Entry Point Not Found
The procedure entry point ?PerformCreateWindowEx@WWindow@@QAEXKPBGKHHHHPAUHWND__@@PAUHMENU__@@PAUHINSTANCE__@@@Z could not be located in the dynamic link library C:\Steam\steamapps\common\Unreal Gold\System\WinDrv.DLL.

After ok'ing that, a second identical error message. Then a third, final one-
Critical Error
Can't find file for package 'WinDrv'
History: UObject::SafeLoadError

I'm now realising that maybe this render is for UT only

That is correct. A compatible renderer must match the game and the patch version (a renderer for UT v436 is guaranteed to work only on UT v436).

in which case I guess I need to reinstall Unreal Gold to get a working windrv.dll/int?

If you can obtain a compatible WinDrv.dll in other way, then reinstalling the whole game is unnecessary.

for your game system folder
C:\UnrealTournament\System
http://medor.no-ip.org/index.php?dir=Patches/&file=WinDrv.zip

Thanks guys. I ended up reinstalling the 277i patch (stupidly without backing up user.ini - my bindings, my beautiful bindings! ) and that made the game functional again.

Also, it turns out that for some reason the Direct3D 8 renderer - not 9, not 10, not vanilla, but 8 - is functional in Windows 10. No HDR with that one, but it looks better than 227i-vanilla OpenGL to me, so I'll chalk that up as a net win...

I definitely need to update this one again, a lot of things have been improved meanwhile with XOpenGL, but a few words for HDR. There is D3D10 by Kentie which "sort of" does it, but this is kinda fake HDR (which is not uncommon though) and the methods used there are neither very accurate nor beautiful imho (in relation to Unreal/UT).
If you read some about HDR you'll notice quickly that not only a renderer capable of doing it is needed, if really correctly done it requires a lot of more things in the background, like reworking/recreating the existing textures and especially in Unreal and UT adjusting the lighting (or entirely redo it). It quickly looks unnatural and odd otherwise.

I definitely need to update this one again, a lot of things have been improved meanwhile with XOpenGL, but a few words for HDR. There is D3D10 by Kentie which "sort of" does it, but this is kinda fake HDR (which is not uncommon though) and the methods used there are neither very accurate nor beautiful imho (in relation to Unreal/UT).
If you read some about HDR you'll notice quickly that not only a renderer capable of doing it is needed, if really correctly done it requires a lot of more things in the background, like reworking/recreating the existing textures and especially in Unreal and UT adjusting the lighting (or entirely redo it). It quickly looks unnatural and odd otherwise.

As you may be know i'm user UT99.
The the most wonderful render for the warmth of the colors is built basic with the creation of UT is Glide.
http://medor.no-ip.org/index.php?dir=Video_Renders/Glide/

It is not easy to run as 32 bits.
In my opinion it is Glide the most interesting to develop.

Want to test it
dgVoodoo1.50Beta the 2 .dll the .vxd and the .ovl in C:\UnrealTournament\System

When developing XOpenGL I soon started to notice that every renderer doesn't entirely look the same and in the beginning I was missing the bit the fully color rich OpenGL/D3D9 look I was used to play with.
After a while things equaled out a bit but I also noticed that it is VERY VERY much depending on what you are used to. Now playing with XOpenGL for the most time for some months it feels somewhat wrong using OpenGL/D3D9 instead.

That being said, I can fully understand your opinion, after all UEngine1 was developed pretty much for Glide back then, hence you can expect the closest match to what the developers/mappers had in mind. Then again, a big part of custom maps however have been probably made with D3D or OpenGL again...
I can't deny that I personally don't like the glide look very much (anymore) after all these years

Hello guys,

I can't seem to get XOpengL to work in Unreal Tournament. I''m following the instructions but unfortunately it's not working. Can someone explain step by step how they got it to work. Thx

hey
Well actually you only have to put the dll's into your UnrealTournament/System folder, and add the missing XOpenGL entries into UnrealTournament.ini
Then you have to change the renderer either in ini or in advanced options to XOpenGLDrv and maybe adjust the settings for XOpenGLDrv there. If you get anny error messages, let us know.

Hey!
Thanks a lot. The only one that worked was 1.0.0.2. all the other ones I get this error message.

Critical Error

General protection fault!
History:UXOpenGLRenderDevice:DrawComplexSurface < -
URender:DrawFrame < - UXOpenGLRenderDevice::DrawTile < -
UCanvas:WrappedPrint < - (Press ESC to begin.) < -
UCanvas::execDrawText < - (CHNullHUD CityIntro.CHNullHUD0 @
Function Botpack.CHNullHUD.PostRenderer:00FB) < -
Uobject::ProcessEvent < - (TMale1 CityIntro.TMale0, Function
Engine.PlayerPawn.PostRender)

Would it be possible to add FrameRateLimit option to this renderer, to make it consistent with opengl/dx9? Many people including myself don't like to use vsync, and capping the framerate with an external utility seems like a needless complication.

Forgive me if I'm being overly critical and firm for a mere end user, but I just thought I'd echo the above sentiment.

When the game goes over a certain fps level near ~300 (I think, it may be related to other things), the game speeds up massively when playing offline against bots. It's also very janky online, with stuttery movement, positioning errors (when in motion, your visuals don't match where the server thinks other players are or where you're shooting - tested in a 56ping server against a bot in 1v1), and causing the player to be unable to dodge (guessing the local timescale is the culprit even if the server isn't running that fast).

Given my modern mid-range PC runs between ~250 and 800 fps 95% of the time, this is a significant problem for me.

Vsync is not a solution, as it introduces input lag - which is intolerable for a fast paced FPS like UT99. In my case, adaptive Vsync is entirely irrelevant, as Vsync would be enabled all the time anyway.

Given an external program like RivaTuner typically adds input lag as well, either the game needs to run at the correct timescale regardless of framerate, or a framerate limiter needs to be added.

Only saying this as it seems there's a chance this is may be what the game is using going forward. Thanks for the work you're putting in, really. It's great this classic game is still getting development attention.

the reason why it speeds up massively offline is because you're no longer connected to a server. your netspeed online effectively is a framerate limiter -- try setting netspeed super low like 200 and you'll see your FPS tank. you can use the command "netspeed 200" to change it. 20,000 is "LAN" (a measly 9.76~ kb/s)

the reason why it gets worse at higher frame rates is because the engine tries to clamp ticks (in this case when offline, frames) to 120. It doesn't really like frame rates above 120 for this reason. The rendering gets "ahead" so to speak of the actual in-game physics and weird shit happens. I'm not sure how unreal engine 4 handles this, but i'll go take a look to see if they changed the clamping in gameengine. Why ue1 doesn't enforce the tick cap and tie the frame rate I don't know, since dedicated servers clamp the tickrate to 120 no problem.

Looks like UE4 does no such clamping, instead has some algorithms to keep framerate consistent, or arbitrary FPS limits.

Because with the "standard" UT brightness value (0.5) it's all more.....bright

AMD Radeon HD 7850
OpenGL "Core" -> 25 FPS

Have tested it on a HD 7850, R9 380 and RX 570 - got the same result, regardless the video card model. Framerate depends on the CPU single thread performance, around 25 (+/-5) FPS.

It seems these video card models can only work normally with D3D* renderers (else OpenGL renderers for UT give not good results also, though better than XOpenGL).

I have an RX 580 and I cannot use anything OpenGL without some serious stuttering. I wish I could use this renderer with my card, it's awesome that people are still developing/optimizing this engine.

i have a rx 580 nitro/ wih a ryzen5 and it works fine and beyond with opengl.  i get like 300 fps with frame limiting off. and i am running it on 227i

edit , i may have mis unreer stoofd the trender and game you playing
edit 2: tested in ut99 and set to xopen gl and i dont see any *loss* of performance over the normal renders
48 - 60 fps and smooth in timedemo
idk if i am testing it wriong

What are your settings for the RX 580? Did you enable OpenGL buffering? Maybe I'm using the wrong dll. I wish I could upload images to show the error message I get (something about entry point not found).

Edit: I found another .dll and now I don't get the error message. I still don't get smooth FPS. So far I've gotten the best results with a D3D10 renderer that I found somewhere years ago. This XOpenGL renderer sounds awesome, I wish I could use it.

A newer version will be included in the upcoming patch for UT, but I'll try to find some time updating this version here, there have been a lot of improvements.

Hey Smirftsch,
Thank you for helping out the community.

I've been using the latest version this video driver lately, and I noticed a few visual bugs while using this driver in-game.

In particular, the fog appears to be bugged in the maps that use it. Also, at certain FOVs, weapons such as the minigun, flak cannon and redeemer appear 'clipped-off'. At FOVs less than 90, weapons appear normal, but at higher FOVs their models don't properly render.

I did read through some of the older posts - looking for solutions to the problem - and it looks like someone experienced similar issues; however, it appears they were fixed at a later time based on the patch note left on the 1st page. Dunno if I'm currently the only one experiencing this in the latest version or if there is potential fix I missed somewhere.

Thanks.

Different FOVs (90 vs 100+)





Fog

There have been a lot fixes, just that I was unable lately to provide something new here. Plain to much work. I'll see what I can do, but the new UT patch also contains a very recent version of it

That sounds great Smirftsch.