WIP: Support >60Hz (2nd try)

[DanielGibson]

Based on @dezo2's patch (see also), but adjusted to make the framerate configurable with the com_gameHz CVar + my own fixes, also some ideas from Stradex' branch.

Very much WIP, and no guarantees this will work out

---

TODO

Potential bugs that have been observed with various attempts of running dhewm3 with >60Hz and that are worth testing:

• Crashes with crane in Alpha Labs Sector 3 (should be fixed by patching GAME_FPS and GAME_FRAMETIME in the scripts)
  • Should really be fixed now, was actually something with SetSpeed() in C++ code that I first fixed incorrectly
• Chaingun shooting too fast (should be fixed by patching CHAINGUN_FIRE_SKIPFRAMES in script)
• Flickering particles (happened with com_fixedTic -1, might not be relevant here?)
  • Haven't seen this issue so far (and no one else has reported it either)
• Switching Mods/game modes can cause black menu for multiple seconds to minutes
  • I can still reproduce this bug. I think it's related to counting tics (com_ticNumber?) and then multiplying it with USERCMD_MSEC and comparing the result to Sys_Milliseconds() or something, combined with one mod having a different com_gameHz value than the other, so tics are longer/shorter. Needs more investigation..
    Should be fixed
• RoE gravity gun only works after 2 minutes or so (haven't tried this yet, might be similar to the previous one)
  • I couldn't reproduce this with my branch, if anyone runs into this problem please report!
• I found if I tweak the fps higher than the monitor refresh rate, NPCs and mobs in-game will no longer interact with stairs. I think this is not a bug related to this fork, cause I found it in BFG Edition too. (again from same bugreport on simonedibilio's branch - this sounds extremely weird)
  • Update: I don't think this has anything to do with monitor refresh rate, but it seems to happen at >= 250fps (and at >= 200fps or so it already looks quite twitchy). I can reproduce it, see first level T. Washington and Mars Sec Anthony, in section between overhearing Betruger and the restroom door
  • According to dezo2's comment this still happens, esp. at framerates where the frametime is no integer (e.g. with 240fps it happens, with 200 not)
    • It also happens with 333fps (3ms frames) and 250fps (4ms frames), so I don't think this is directly related to integer frametimes, though it could be that at <= 5ms it generally starts to get real glitchy
  • Fixed!
• Savegames don't work, "Script checksum didn't match"
  • Fixed as far as possible: This update will break savegames, i.e. loading old savegames will make you restart the level the savegames is from. This is due to changes I had to hack into the scripts, can't be avoided.
    But at least (unlike in Stradex/simonedibilio's branch) they don't break every time you change com_gameHz, so from now on they should be stable again.
• the console cursor (and probably other cursors?) also changes the flashing frequency with different values for com_gameHz
  • fixed
• The d3xp grabber feels worse at high FPS somehow, for example in that bossfight in erebus2. the grabbed things slow down way too fast and sometimes fall down before being in front of the weapon where they should be held for some time
  • fixed
• "I saw maybe 2 or 3 physics related glitches where imp couldn't jump out of his hole due to a moving part in the path." "IIRC the glitches were in map recycling1/2 somewhere (can't remember) and in RoE map erebus4 in the beginning where that new imp couldn't leap down from the ceiling."
  • Can be reproduced, see comments below. Not sure if the physics are generally buggy now, or just behave a bit differently (so for example stuff falling to the floor lands at different places and possibly blocks monsters it didn't block before)
  • This seems to be rare enough, and usually the affected monsters turn up eventually, so I could live with this bug
• Oxygen drainage too slow or fast (should be fixed by modifying the "air" code in idPlayer)
  • Mostly fixed, still TODO: changing com_gameHz while Oxygen is active is buggy
• Make sure that game frames aren't longer than 17ms, because apparently not only too short frametimes, but also too long frametimes can screw up physics. Just call idGame::RunFrame() multiple times if com_gameHz is too low
• It would probably make sense to check at runtime if the configured com_gameHz can be reached (and is not slowed down by vsync or simply a slow computer), and show a warning or something if it can't, telling the user to configure a lower value or otherwise fix their settings
• Getting stuck in delta4 at a fence in the gateway at the very beginning, at >= 173fps (see this comment)
• Player sometimes getting stuck at stairs (the higher the FPS the worse it is), for example at beginning of hell1, see this comment
• The Mancubus in hell1 behaves weirdly at 480fps, and "jumps a lot after killing it" (same comment as previous item)
• Multiplayer must be tested (do clients and server all running at different com_gameHz work?)

[DanielGibson]

This time I was lazy and kept USERCMD_MSEC and USERCMD_HZ around, just turning them into #defines that alias global variables storing the current values.
Not sure how great that really is, but at least it reduces the amount of changed code significantly, as most (but unfortunately not all) code using USERCMD_MSEC/HZ just continues to work without modification.

[DanielGibson]

Ok, I think I have fixed the "Switching game modes can trigger a fake black screen" issue, by fixing how com_frameTime is calculated.
I couldn't reproduce the issue with the grabber either (after the fix, didn't try before).

At least on my (Linux) PC, the framerate is extremely stable now (with vsync disabled), but not at the rate configured with com_gameHz, but the next multiple of int(1000/com_gameHz), e.g. 63fps for 60hz, 125fps for 120hz, 143fps for 144Hz, 250fps for 240Hz.

I guess I should try using floating point (double) times at least for the async tics, but probably I should also try how that all works on Windows and how it interacts with vsync.

---

However, all this somehow feels wrong: I can't find it right now, but I think there are comments in the code stating that the tics are supposed to be incremented at 60Hz, and that this is supposed to be independent of the render framerate.
But OTOH, they obviously didn't implement (or at least ship) that in Doom3, so maybe they discarded that idea and just forgot to remove some stray comments.

On the other other hand, I don't see the point of that whole async thread for incrementing tics, no matter if the renderer is running in sync with the game or not.
If one wanted to use threads there, it would probably make more sense to run the gamecode and the renderer in different threads, than having an additional thread just for incrementing a counter every 16ms...

[j4reporting]

the console cursor also changes the flashing frequency with different values for com_gameHz

[DanielGibson]

the console cursor also changes the flashing frequency with different values for com_gameHz

true, I've also noticed this already, will add it to the list (I also know why it happens, just doing other changes first)

[DanielGibson]

I've pushed lots of changes in the last hours.
One thing is that I rebased this on the soft-particle branch, so both features can be tested together (I'll post Windows binaries later).

Another is that the framerates should now be very close to what's configured with com_gameHz (unless VSync or a slow computer slow it down), because the timing of frame starts is now done with much more precision than full milliseconds.

Most times in the game and engine still use full (integer) milliseconds, like before, so I wonder if this causes any issues or if starting the frames at the correct time is good enough for things to run smoothly.

[j4reporting]

looks goot so far, played up to 1st airlock in mars city underground.

There is an issue with the air supply though. It can be manipulated by changing com_gameHz while being outside

com_gameHz 500 -> cycle airlock then set com_gameHz to a lower value
com_gameHz 20, then again to 10 > 4000

changing com_gameHz to a higher value than configured has ofc the opposide effectl

[DanielGibson]

(rebased this branch again, to current master, so it includes the fix for #587)

I'll look at the oxygen issue.
I don't think it's critical though, changing com_gameHz while outside is quite an edge-case ;)

[DanielGibson]

Thanks for testing by the way, I appreciate that you're doing this, and how thorough you are! :)

By the way, does dhewm3 at higher framerates feel smooth?
(Or does your display only support 60Hz anyway so there's not much visual difference, unless a bug introduced additional stuttering?)

[j4reporting]

It was a coincidence, I changed the setting while i was still in the airlock, but after I already initiated the airlock cycle.
I wonder what other scripted/timed events could be prolonged in this manner?
I guess in the end you'll need a fps independent internal value/timer.
THe same happens with loading a savegame craeated with a different com_gameHz setting.
maybe keep a 60 FPS value around and save only this value in a savegame.

Desktop is set to 144Hz. I would not want to go back to 60Hz.
Higher FPS feel ok. No stutter, nothing feels very good so far. Tested on WIndows with 144Hz and tied 250 for a while as well. Ofc not much is happening at this stage of the game.
Unexpectedly, I had some time to spare, because the Austria - Turkey game was only on a strangly colored pay-TV channel. Sometimes it's an advantage to follow a game via audio stream only.

[DanielGibson]

I guess in the end you'll need a fps independent internal value/timer.

I do, it's just that some code (incl. some scripts) uses the game tics that are incremented each frame, and at a higher framerate they increment faster..
The fixes so far have been to at least scale the amount of tics a function waits (or sets as a limit, for example for "then I'll be out of oxygen") by com_gameHz/60 (=> for 120fps wait for twice as many tics), but as you noticed if com_gameHz are modified after such a "target tic number" has been set, you get glitches.

But maybe I could change the logic to use a floating point tic number and then scale the added value each frame (at 120Hz add 0.5 instead of 1 tic), so the target tic would remain the same.. I just hope this isn't used by too much code besides the oxygen.

Or I'd have to re-evaluate going back to 60Hz tics for the game code and only render at a higher framerate, but I'm not sure if this is feasible (and if there is even a point to that: what use are 120fps if nothing changes every second frame? but maybe something can be done without increasing the tic, I'll have to look at how the prediction code for multiplayer works, it might be related to this..)

nothing feels very good so far

why not?

[j4reporting]

nothing feels very good so far

why not?

aaaaah. damn.

No stutter, nothing. Feels very good so far.

[DanielGibson]

Here is a build for Windows: dhewm3-1.5.4pre-highfps_win32.zip
Note that it does not support any mods for now, only the base game and RoE.

This contains both the soft particles changes and this high FPS stuff.

Other new features:

• r_displayRefresh allows setting the display refresh rate for real fullscreen mode (unless you're using Wayland, it doesn't support that)
• com_showFPS can now be set to 2 to also show avg/min/max frame times in ms

[DanielGibson]

Based on the comment from @dezo2 at #250 (comment) I tested d3xp Erebus4 and yes, that new Imp near the start of the level definitely doesn't spawn (or drop?) like it should when running at 120 or 144 or 240 fps (it still seems to work fine at 60).

It should come out of the black hole that arrow is pointing to:

It eventually is there, at least if I stand directly below that hole, but at 60fps it drops down that hole pretty soon after that panel from the ceiling falls down after entering the room.

Something else I noticed is that things completely fall apart when I change com_gameHz while the game is running (loading a savegame again fixes it).
No matter if I increase or decrease it, and if it's only by a little bit (like 120 -> 121), I get weird moving double images (note that despite the muzzle flash I'm not currently shooting):

No idea what's going on there, or if the issue is in the scripts or C++ code or whatever.
UPD: That double vision problem seems to be related to me messing with the slowmo state in idGameLocal::SetGameHz().
Still no idea about the Imp (only thing I noticed is that it most probably does spawn, as I heard it hissing).

[dezo2]

I got finally some time before going back to work so I just want to thank you Daniel for working on this. I tested the base game briefly and the game movement seems fine. What I found so far using com_gameHz 200 and 240 with VSync on a 240Hz VRR monitor:

The crane at the start of map alphalabs3 doesn' t come up when I press the button and crashes the game (something about binding an object to itself). Which is strange because the chaingun firing rate is OK, so the scripts should be adjusted.

There is a slight problem with 240Hz using VSync in cutscenes, where the audio sync (lipsync) drifts after a while even with default com_fixedTic 0. This is minor and can be fixed by running the engine at 200Hz (5ms int) - you can test it with map mars_city2 at the start, the survivor up the ladder there speaks relativelly long.

I also noticed very brief frame skips when the Hz does not match the integer framerate like 240Hz and again they dissapear when using 200Hz or by setting com_fixedTic 1. The frequency of the skips seems to match the difference between int and float frametimes so at 240Hz 4.1666ms they are realtivelly far between.

The imp in RoE should come down if you kick the panel under the hole - seems like the spawn is somehow tied to the panel position as it lands differently when it falls down before the imp at FPS >60.

I will continue testing when I have some time.

[dezo2]

The crane crash is not caused by the scripts after all, I tried it with my old code and it needs the SetSteerSpeed adjustment in Physics_AF.h, it was this line in the code:
void SetSteerSpeed(const float speed) { steerSpeed = speed * 60.0f / USERCMD_HZ; }

But I thought you did something similar it in your new code, so not sure what's going on.

[DanielGibson]

Thanks for testing!

seems like the spawn is somehow tied to the panel position as it lands differently when it falls down before the imp at FPS >60

Hmm interesting theory - maybe the panel blocks the spawn position or something?

SetSteerSpeed(const float speed) { steerSpeed = speed * 60.0f / USERCMD_HZ; }

I just realized: I replaced that code with
SetSteerSpeed( const float speed ) { steerSpeed = speed * gameLocal.gameTicScale; }
but gameTicScale is gameHz/60 (the factor for "how many more tics do I need to wait for the same amount of time") - so it must be steerSpeed = speed / gameLocal.gameTicScale; instead.
Same for STOP_SPEED

[DanielGibson]

Just pushed a commit that fixes the crane (I tested the crane and didn't have crashes with 120, 240 or 60fps)

[DanielGibson]

Updated Windows build: dhewm3-1.5.4pre-highfps2_win32.zip
Most important fixes since last build: Crane works now, so does changing framerate in d3xp, cursor blinking speed is normal at all framerates, com_showFPS 2 shows avg/min/max frame times of all frames in last 0.5 seconds.

---

By the way, some suggestions for testing:

• Don't forget to increase the framerate ;)
  • In the new menu, which can usually be opened with F10, it's under Game Options -> Framerate
  • Enable com_showFPS to see if the game actually runs at that framerate (VSync might prevent it)
  • You don't necessarily need a display that supports >60Hz. You should not see much of a difference then (compared to how dhewm3 looked/ran before these changes), but most bugs should also be visible when running (without VSync) with 120 (or 144 or 240 or whatever) FPS on a 60Hz screen.
  • And of course testing if 60fps still behave like before is also valuable
• Save frequently (maybe even increase com_numQuicksaves) and if you run into a bug, make backups of the last one or two quicksaves, which can hopefully help to reproduce it
• Please report the map an issue happens in, ideally take a screenshot of the place, and run getviewpos or where in the console (and report the output) - it will print at what coordinate in the level you are.

[dezo2]

Tested RoE yesterday with com_gameHz 200 and was able to run from start to finish without problems (apart from that one blocked imp in erebus4). No crashes or game breaking bugs, enemies went up/down the stairs to find me, grabber/slowmo/oxygen/enviro suit/machinery/elevators/bridges all worked as expected, so to me the code is already very usable. I will also try the base game but don't really expect any major problems there. BTW thanks for the F10 hidden menu tip, didn't even know about it.

As for the second blocked imp, it's in the base game, map recycling2 (-494.73 1410.72 -11.75) 190.2, right after interaction with the left screen. Imp should jump out of his closet, but with FPS >= 85 (11ms) he will be blocked with a panel he tried to kick out. So similar situation to than one in RoE. Not sure if this can be fixed without breaking something else in the physics code.
QuickSave.zip

[Terepin]

I just wanna point out that the original Doom 3 can now run at higher fps than BFG edition. What a time to be alive in.

[dezo2]

I may have found a fix for the blocked imps and potentially other enemies hidden behind wals and panels. This was caused by the STOP_SPEED in physics being too low for higher FPS, so by replacing a line in the source files Physics_RigidBody.cpp (base and d3xp):
const float STOP_SPEED = 10.0f / gameLocal.gameTicScale;
by this line:
const float STOP_SPEED = 10.0f * gameLocal.gameTicScale;
all the blockages seem to be fixed including the imp in RoE erebus4 and the one I posted yesterday. This should also fix the wild enemy ragdols and panels movements after explosions etc. Now at 200 FPS they all look similar to 60 FPS. Hopefully this won't break anything else. I will continue testing with this but I think this can be it.

[dezo2]

Crap, celebrated too soon. It works with 200 FPS but not with 144 or 120. The physics code is seriously weird. The STOP_SPEED has to be the culprit for these problems.

[DanielGibson]

Just a quick note: I configured automatic builds for dhewm3, so whenever changes are pushed to the master branch or an open pull request (like this one), new binaries for x86_64 Linux and 32 and 64bit (x86 and x86_64 aka x64) Windows are automatically built.

(There's a also a build for arm64 macOS, but I have no idea if that works without adding SDL2 and OpenAL-Soft to the app bundle somehow, and also it's probably not signed.. so the automated Mac build is mostly to make sure dhewm3 compiles on that platform at all)

You can find the builds at https://github.com/dhewm/dhewm3/actions and after selecting a "workflow run", the resulting binaries can be downloaded under "Artifacts".
NOTE that you need to be logged into Github to get the download links! That's a restriction from Github that I can't do anything about.

[ALord7]

The character's head twitches strangely on the cpu map

I also noticed this at 60fps in dhewm3 1.5.4
Perhaps this happens if the player is standing too close

[markanini]

The only thing I noticed in the latest automated win64 build 1bd8ca6, tested at 144Hz, are two Imp encounters in Recycling 2, the the wall panels block the Imps paths.

The first Imp encounter corresponds to 9:49 in this playthrough video https://youtu.be/qNAcdZQG0-s?si=Qk3p181neGotICe6&t=589

Dezo 2 reported about the second Imp encounter here: #585 (comment)

[markanini]

One minor graphical glitch, on the interactive panels of the Lab door in Site 3.

[markanini]

This one is intermittent, another minor glitch, when quickloading a white bar appears.

[gex581990]

One minor graphical glitch, on the interactive panels of the Lab door in Site 3.

I haven't experienced this at the same area but I'm at 120fps/120hz so maybe it's just something over 120hz? also I do have an extremely customized config and mods applied so who knows if something else is helping me there. I'm also using the 64-bit Windows version of this branch

[markanini]

If I try dispatching the spiders in one location in Erebus Station using the grabber I get this error.
QuickSave2.zip

[tyuah8]

I -think- this should be enough to remove the sliding. Below is a save from recycling2 with imp walking to test it. Daniel please update the modified code row in function idPhysics_Monster::StepMove in both Physics_Monster.cpp files when you have time.

// try to move at the stepped up position
stepPos = tr.endpos;
stepVel = velocity;
// DG: this hack allows monsters to climb stairs at high framerates
idVec3 fixedDelta = delta * ( tr.fraction < 1.0f ? 1.0f : gameLocal.gameTicScale );  // <--- modified
result2 = SlideMove( stepPos, stepVel, fixedDelta );
if ( result2 == MM_BLOCKED ) {
	start = noStepPos;
	velocity = noStepVel;
	return result1;
}

test_imp_rec2.zip

Even with this change, I think you will find that NPCs still move far too quickly on sloped surfaces. You can see this with the trites that appear during the second vacuum in Communications Transfer.

[LasseK1981]

Here is a build for Windows: dhewm3-1.5.4pre-highfps_win32.zip Note that it does not support any mods for now, only the base game and RoE.

This contains both the soft particles changes and this high FPS stuff.

Other new features:

• r_displayRefresh allows setting the display refresh rate for real fullscreen mode (unless you're using Wayland, it doesn't support that)
• com_showFPS can now be set to 2 to also show avg/min/max frame times in ms

Hello Daniel. I am not a developer but wanted to give you my 2 cents on testing DHEWM3 in various versions with 120 fps. First of all I wanna say thanks for your work for the community.

However I want to note that there are severe performance issues with high FPS dlls since the first one I tried that only worked for version 1.5.1. This was supplied from the user DEZO2 and here are the link: #230

I dont know what the difference is from his approach to every other I tested from 1.5.2 to current 1.5.4. But his version runs very fast and smooth and does not max out the 1 cpu core the game runs on. This is the best dll to date performance wise. Now I have a 14900KS running 5.9 Ghz but with every other DLL in 4K with other mods it just tanks the 1 cpu core and gives a very bad game experience... the game comes down into slowmotion often and all the way down to 60fps which will result in 50% game speed with the dll. I just wanted you to know I think you should pursue his way of doing it. Now I have both Base Doom 3 and ROE running perfect with 1.5.1 and his dll. But the Lost Mission addon requires unfortunatly at least 1.5.2 to not make bugs and the last Hell Outpost simply dosent work on the 1.5.1 version. But the com_gamehz is very bad in performance and this is on the fastest cpu on the market at this time. Anyway I just wanted to give you my 2 cents on it and hope you guys may want to pursue that technique instead.

[LasseK1981]

I -think- this should be enough to remove the sliding. Below is a save from recycling2 with imp walking to test it. Daniel please update the modified code row in function idPhysics_Monster::StepMove in both Physics_Monster.cpp files when you have time.

// try to move at the stepped up position
stepPos = tr.endpos;
stepVel = velocity;
// DG: this hack allows monsters to climb stairs at high framerates
idVec3 fixedDelta = delta * ( tr.fraction < 1.0f ? 1.0f : gameLocal.gameTicScale );  // <--- modified
result2 = SlideMove( stepPos, stepVel, fixedDelta );
if ( result2 == MM_BLOCKED ) {
	start = noStepPos;
	velocity = noStepVel;
	return result1;
}

test_imp_rec2.zip

Even with this change, I think you will find that NPCs still move far too quickly on sloped surfaces. You can see this with the trites that appear during the second vacuum in Communications Transfer.

I just wanted you to know I tested all the fast fps DLLs since 1.5.1 and this DLL made by DEZO2 is the best by far! I just completed the game with his and there were absolutly no bugs or errors or major timing issues. However every dll I tested since 1.5.2 made by others based on (I think!) com_gamehz has be very bad in performance and made a lot of timming issues. You should try his DLL and 1.5.1 here: #230 I have a 14900KS at 5.9 Ghz and with all other dlls from 1.5.2 the performance tanks 1 cpu core and slow mo the game quite often with other mods enabled in 4K. Because how its made it sometimes goes down to 60fps resulting in 50% game speed which is unplayable and very annoying. But with 1.5.1 DEZO2 dll I had NO performance issues with same mods and 4K. And the game ran incredibly well! I also completed ROE with same DLL with no bugs or timing isses. The only thins is that the Lost mission addon has severe bugs on the last mission in particular HELL OUTPOST and will simply not load on 1.5.2 .. SO thats very annoying.. All the mods I combined for the test were.. REDUX 20th, SIkkmod shaders, Runners Doom, High poly models. SO quite a pack and graphic orgie haha! :) But it can manage fine in 120 fps with no frame drop in 4K with DEZO2 DLL.

[DanielGibson]

Note that the current builds of this branch are either this one:

Updated Windows build of this branch: dhewm3-1.6.0pre-highfps_win32.zip

Or, even more up-to-date, the latest "artifacts" of an automated build of this branch from https://github.com/dhewm/dhewm3/actions?query=branch%3Akickstart-my-hertz
for example: https://github.com/dhewm/dhewm3/actions/runs/10481813058

You'll need both the dhewm3.exe and the DLLs (base.dll and/or d3xp.dll)!

If you're having performance problems, it might be worth a try to disable soft particles (r_useSoftParticles 0 or in the new Settings Menu under Video Options uncheck ☐ Use Soft Particles). It often also helps to reduce anti-aliasing.

[ALord7]

Try changing your anti-aliasing settings first. In my case it helped a lot

[LasseK1981]

Try changing your anti-aliasing settings first. In my case it helped a lot

Thanks, I play without the AA. With it, its a no go haha! The reason why its extra demanding on my setup is because I use this mod also in 4K called RUNNERS DOOM. It enhances all plasma and demon plasma shot significantly. But the slow down is most noticeable in larger room/ areas. But again the first 1.5.1 dll does not have these issues.. I can run full on with absolutely no fps drop. Although I can see the CPU can be in the 90s% it (luckily) never reaches 100% ... But I was not aware of the soft particle thing.. maybe thats it? IT would sure make sense.. I am about to test it now.

[LasseK1981]

Note that the current builds of this branch are either this one:

Updated Windows build of this branch: dhewm3-1.6.0pre-highfps_win32.zip

Or, even more up-to-date, the latest "artifacts" of an automated build of this branch from https://github.com/dhewm/dhewm3/actions?query=branch%3Akickstart-my-hertz for example: https://github.com/dhewm/dhewm3/actions/runs/10481813058

You'll need both the dhewm3.exe and the DLLs (base.dll and/or d3xp.dll)!

If you're having performance problems, it might be worth a try to disable soft particles (r_useSoftParticles 0 or in the new Settings Menu under Video Options uncheck ☐ Use Soft Particles). It often also helps to reduce anti-aliasing.

Ok, I have now done some very thorough testing! It seems like no matter which DLL I choose it will make the FPS slowdown in a particular "test place "I found. Its much worse than other places apparently and that is the LOST MISSION HELL and HELL Outpost. Even with the 1.5.1 it does the same! I also tried with soft particles off.. I went through all versions and no difference. So I guess I just found the meanest place to test it. Lost Mission Hell (huge open area right at the start) I dont know if the latest dll´s are based on the same thing? or is there a difference between the versions? 1.5.1, 1.5.2, 1.5.4? 1.6.0? Because other places I did notice much much better performance with 1.5.1 compared to 1.5.2 .. I have not tested so much other places and with later builds like 1.5.4 etc... But I just completed the base game with REDUX 20th and much more and it performed much much better, actually perfect compared to 1.5.2 com_gamehz But a side note... Remember when I said that 1.5.1 did not work with final level in LOST MISSION HELL_OUTPOST? Well now after testing all the version including 1.5.4, 1.6.0 and latest build 1.6.0 I can confirm neither of those work with that final level! However strange enough 1.5.2 works! the reason why it does not work is because there are some warnings and errors with the LOST MISSION scripts, I can see that its the final boss script. And apparently Doom3.exe and 1.5.2 kind of ignores that were all other DHEWM3 version HALT the game. (This is also with a clean install and clean LOST MISSION 1.4 ... Just for your information.. I dont know if its a custom version but the filename was: unlocked-fps-rw-v0.1.0-dhewm3-1.5.2_win32. I got it somewhere from in here. Its just a shame the latest does not work with this final level, at least in my testing. Unfortunatly the 1.5.2 unlocked-fps-rw-v0.1.0-dhewm3-1.5.2_win32 has the worst performance of them all. This goes down in my "plasma" test to the 20s fps (with mods). These test are in a huge open area at the start LE_HELL Lost Mission, but also rest of mission in lesser amout but "unplayable".. So there has to be a difference in how these DLLs operate. But the hell missions are for some reason more tough than the others. But this LE HELL is brutal .. I just tried completely vanilla also wiht 1.5.2 and it max out the 1 cpu core also when much "action" on screen. Also when I have mods I noticed that plasma particles and BFG particles etc. are really demanding for the CPU? Have no idea why, as I thought it was done by the GPU. This runners mod makes some beautiful BFG and plasma shoots but they almost push the CPU to the limit in many cases?! Could it be scripting? Or just the way it works the DLL? But thanks for the 1.6.0 ! I really appreciate it .. I will begin over with the base game with mods and let you know how it works for me! :) Now that I just completed with 1.5.1 flawless. I will try with the 1.6.0+ (latest build) you linked! Thanks again! Its great stuff! I remember for years back when I came to the conclusion that I could not play Doom 3 anymore due to 60fps after I got used to 120- So to see you guys take this game to next level with the whole DHEWM3 and 120 fps DLL is really really sweet. This combined with REDUX 20th etc. is amazing! I am sure even John Carmack would say this is PRETTY cool and nice! :D The way he probably imagined the game (maybe) but couldnt due to technical limitations back then. But running this with NVTRUEHDR and REDUX 4K 120fps is incredible! I am running this on a 42" OLED LG C2 as a monitor! :) This game was created for "perfect black". But 20 years! .. crazy..