60fpsFixes: add patch to improve framelimiter above 60FPS

[emoose]

Continued from older PR #25

(with the new framelimiter & UseDynamicFrametime setting in latest re4_tweaks most of this PR is no longer needed, the code that updates the settings menu with new framerates might still be useful in future though, so for now will probably just leave this PR as a draft.
There are still many issues with UseDynamicFrametime though, seems a lot of the game code is set up to only work properly when the frametime is exactly the same between frames, maybe some way of decoupling the graphics rendering from the deltaTime var would be good to look into...)

---

Hooks the ConfigReadINI call so we can update frametime used for framelimiter based on the variableframetime variable - with this it seems framerates above 60 can work without being too broken, likely many issues to be found (and hopefully fixed) though of course.

If anyone wants to try it out, here's a build with this PR:
(E: latest build can be found at #50 (comment))
re4_tweaks1.7.3_framelimit-fix-v2b.zip

(old)
re4_tweaks1.7.3_framelimit-fix-v2.zip
re4_tweaks1.7.3_framelimit-fix.zip

In v2 the ingame settings now includes extra framerates (30/60/90/120/144) - if you want even higher you can edit your RE4 config.ini file.
Framerate should probably be a multiple of 30, but maybe others will work fine too, who knows.

You may need to set DisableVsync in re4_tweaks dinput8.ini if the new framerates don't work for you, or unset fullscreen mode in game settings (or in config.ini) - hopefully if your monitor supports the refresh rate natively it should just work though.

If re4_tweaks shows a message about framerate setting, set IgnoreFPSWarning to true in dinput8.ini (should already be set in the above ZIP)

If you notice anything weird please let us know about it here - most problems are likely things that were set for 30FPS timings, game probably also had the same issue at 60FPS too, but running at higher framerates makes things much more apparent (try using variableframerate 200 if you want to go on a bug hunt :)

TODO (both should be working in latest commit)

• maybe hook ConfigWriteINI as well to also update framelimiter after user changed settings (done via hooking settings menu code)
• find out whether 90/120/144 options could be added to ingame settings (seems possible!)

Framerate TODO

• menu selection is tied to FPS (thanks to @Keith94 for reporting)
• scope/binocular blur is broken again at higher framerates lel
• footstep sounds seem messed up at higher FPS
• enemies seem to turn around much quicker at higher FPS, and attack you almost instantly (so that means 60FPS has been hard-mode this whole time?)

---

Should note that this is different to the other FixSlowdown PR, that one tries allowing game to see the true delta-time between frames, instead of locking the delta-time to an expected FPS - which fixes the slowdown issue when the expected FPS can't be reached, but also exposes a lot of issues in a game that wasn't developed to work like it - if enough time is spent to understand the games animation system I'm sure those could be worked around, but right now there's not really enough known unfortunately.

(RE4VR might give us some clues about that, doubtful that they maintain the full 120FPS+ required for VR at all times, so likely they probably added improvements to allow delta-times, finding where those improvements were made would probably help us a lot - RE4VR was actually built on top of the QLOC port, so a lot of the fixes might transfer over pretty well)

Meanwhile all this PR does is allow game to also make use of 90/120/144Hz frametimes - without fixing the deltaTime issue at all - this seems to allow game to play at higher framerates without as many issues, but still means the slowdown issue happens when the expected FPS can't be reached.

At higher framerates like 90/120/144+ it's much more likely that game will miss the framerate target too, so I wouldn't really consider this a proper fix, mostly just something useful for showing what happens when higher framerates are used.

[nipkownix]

Great work so far!

scope/binocular blur is broken again at higher framerates lel

I imagined this would be a problem lol
Pushed a quick fix, should be working fine.

Also, I was going to push a commit to allow people to change the FPS without having to go back to the main menu, since this restriction doesn't appear to make sense:

// Allow the user to change the frame rate without going back to the main menu first
pattern = hook::pattern("F7 82 ? ? ? ? ? ? ? ? 74 ? 83 3D ? ? ? ? ? 75 ? 6A");
injector::MakeNOP(pattern.count(1).get(0).get<uint32_t>(10), 2, true);

Seems to work fine if I use it with the vanilla FPS list, but it.. forcefully closes the options screen if the custom FPS list is enabled. Not sure why. Feel free to add that in if you can find the problem.

Edit:

Today I learned that my RX 590 cant handle RE4 at 144 fps, lol

Guess we found a test case for the D3DCREATE_MULTITHREADED flag removal

Edit2: not sure what is bottlenecking my game, since the gpu load never goes past 50% and the flag removal doesn't change anything. Hmm.

Edit3: Trash d3d9 AMD drivers probably play a part in this, since I'm getting a performance boost using DXVK. Oh well.

[sindre-gangeskar]

I see that it's already on the TODO list, but it's not just the footstep sounds.

Every footstep sounds like it's multiplied and repeats like an echo, but so do other things too such as
jars and boxes and other actions performed by the player / NPCs such as attacks etc.

Amazing work! Really can't wait to replay RE4 in 120fps mode and with fully remastered textures as well. This is what Capcom should've done in the first place. Once the bugs have been fixed, this'll be the ultimate way to play RE4, I can't wait! :D

[nipkownix]

Gotta say I'm seeing a surprisingly low ammount of bugs at 144 fps. Nice!

Most notable ones were the slower aim speed (for which I pushed a fix), and sound issues like this one:

2022-01-30.19-41-50.mp4

This plaga sound kept looping after I killed it, for some reason.

And yeah, I'm also getting the "echoed" sounds @Crucially-Ultrawide spoke of. It doesn't happen every time, but some sounds appear to be playing twice at the sime time or something like that. Noticed it the most with the ganado voices.

Some other issues I noticed while playing Mercenaries:

This guy's crossbow is emitting waaaay more light than it should:

2022-01-30.19-51-26.mp4

The famous bouncy grenade is back at it again, although this time it doesn't look like it happens every time?

2022-01-30.19-53-01.mp4

Footsteps end up sounding way too loud for some reason:

2022-01-30.20-01-47.mp4

Looks like the plagas don't disappear when you kill them. It was hard to get footage of this, but you can see it here:

2022-01-30.20-06-56.mp4

Might be the reason the plaga sound was looping on my first video?
This does appear affect the other plaga types as well.

The sniper scope takes many more scrolls to zoom in. Not sure if it makes controller zooming slower too, but it probably doesn't. It is probably a side effect of the wheel->RS code being funky.

Moving the sniper when aiming is much slower too. FixAimingSpeed doesn't seem to fix it for now.

[emoose]

@nipkownix those are all with 144Hz right? Have you tried with 120Hz at all? Could be that some of those issues were because of 144Hz not being multiple of 30.

About the sounds and other things being duplicated (some people on Steam forum mentioned things like chickens dropping 2x eggs), IIRC I mentioned in one of these github posts before that main game loop seemed to be running at half the games framerate, (seemed like 60Hz = 30Hz game loop, so maybe 120Hz = 60Hz), wonder if that could be causing some of these issues.
I'll have to dig up that post, perhaps if it was forced to stay at 30Hz it'd stop some of these issues. (or could be that it's still running at 30Hz and needs to be increased somehow)

E: hm not really sure how to go about changing the timing, seems it's relying on something waiting on the render thread..

E2: darn, tried slowing it down by making GXExt_ScreenFlipBuffers loop for certain amount of time, but that just slowed down rendering too, guess there's something else used in WinMain that render thread waits on.

Maybe changing WinMain speed isn't right way to do this, seems that it works fine at 15Hz and 30Hz, so I'd think fixing code for things to work at other speeds should be possible.

Edit3: Trash d3d9 AMD drivers probably play a part in this, since I'm getting a performance boost using DXVK. Oh well.

Wonder if D3D12 would perform better for you at all, I did a quick test of making the game use D3D9On12 but for me it just resulted in a huge performance loss (from ~180FPS down to ~80...), I think I've heard AMD is usually better than NV at running D3D12 though, so maybe wouldn't be as bad.

[nipkownix]

Wonder if D3D12 would perform better for you at all, I did a quick test of making the game use D3D9On12 but for me it just resulted in a huge performance loss (from ~180FPS down to ~80...), I think I've heard AMD is usually better than NV at running D3D12 though, so maybe wouldn't be as bad.

I've tried Josh's whatever it is he named his dll and got a huge performance loss too. Also some geometry was pitch black for some reason. Guess it was shader-related.

DXVK is working nicely though. Still can't maintain 144 fps in every area, but oh well.

those are all with 144Hz right? Have you tried with 120Hz at all? Could be that some of those issues were because of 144Hz not being multiple of 30.

Ah yeah. I'll do some more testing and see if I can reproduce those issues at 120 fps.

Edit:

Plaga issue doesn't seem to happen at 120 fps:

2022-01-31.18-56-45.mp4

2022-01-31.18-53-38.mp4

Crossbow one still does:

2022-01-31.18-54-21.mp4

[emoose]

Hm, just noticed PadRead has some ConfigGetVariableFramerate calls inside it (0x96A606 & 0x96A666), seems to use two different values for something for 30/60, seems easy enough to work out what they'd be for other framerates - @nipkownix do you know if any of your aiming patches affect that stuff at all?

There's also a big chunk of PadRead that only seems to be used when framerate == 60, no idea what it's doing in there though.

[nipkownix]

Not sure if my aiming patches affect that stuff. I wasn't aware there were checks in place. Maybe I should start to check it more often in IDA.

My current patch just tries to make the mouse delta values be consistent regardless of the frame rate, but I did notice it isn't perfect. Maybe the checks you mentioned are messing with it somehow.

Seems like there are three calls to ConfigGetVariableFramerate, but only the last two are actually called? (at least for me on a new game).

Not sure what they're supposed to do. I'm seeing no change when forcing the game to call those sections. Hmm.

[nr1995]

I see that it's already on the TODO list, but it's not just the footstep sounds.

Every footstep sounds like it's multiplied and repeats like an echo, but so do other things too such as jars and boxes and other actions performed by the player / NPCs such as attacks etc.

Amazing work! Really can't wait to replay RE4 in 120fps mode and with fully remastered textures as well. This is what Capcom should've done in the first place. Once the bugs have been fixed, this'll be the ultimate way to play RE4, I can't wait! :D

That repeating/echoing effect occurs with the neck cracking sound after a suplex, even in 60fps.

[emoose]

Would like to update this to latest master but a lot of conflicts there.. @nipkownix maybe it's worth merging the aiming/mouse turning/FixSniperFocus stuff into master seperately of this PR? or have those already been merged maybe?

[nipkownix]

maybe it's worth merging the aiming/mouse turning/FixSniperFocus stuff into master seperately of this PR? or have those already been merged maybe?

Well, they haven't, but they're not really necessary unless we go above 60 fps. Meh.
I went ahead and rebased the PR on top of the latest master for you. Just tested a bit and everything seems to be fine.

[emoose]

Ahh right, wasn't sure if there was anything here that might have applied for 60FPS too.

Thanks for the rebase! Here's a build for anyone that wants to try it out:
dinput8-framelimit-fix-v3.zip

E: here's a version with the debug console hidden:
dinput8-framelimit-fix-v3-noConsole.zip

Make sure to use the included INI with that too - if you have issues running above 60 try toggling fullscreen in-game, or edit your games config.ini so first line ends with your desired framerate, eg. resolution 1920 1080 120.

Like I mentioned on Steam thread I haven't seen any major gamebreaking issues with this yet, mostly seems to just be audio related surprisingly, and there might be an issue with grenades exploding too (but that might only happen at 144Hz or other non-divisible-by-30 framerates)

Would still be interested in hearing of any other weirdness that it might cause though.

[emoose]

BTW if anyone finds any duplicated-sounds which can be triggered somehow (eg. moving into certain area triggers it, or pressing a button or something) please let me know, would help a lot with finding what causes that... (or is that not a problem with 120FPS, only 144?)

[sindre-gangeskar]

BTW if anyone finds any duplicated-sounds which can be triggered somehow (eg. moving into certain area triggers it, or pressing a button or something) please let me know, would help a lot with finding what causes that... (or is that not a problem with 120FPS, only 144?)

It happens at 120fps as well. Breaking objects such as the vases and boxes repeats as well as the footsteps etc. Been a while since I checked but I’ll try to get back to it and look for other audio issues while playing when I get back home.

[nipkownix]

Will update this PR soon. The master branch is now hooking the mouse delta stuff as well, so I'll need to adapt the aiming speed fixes here to fit there. (these shouldn't even be needed when using raw input though)

[nipkownix]

Updated to include the latest raw input work:
dinput8-framelimit-fix-v4.zip

The mouse aiming speed fixes ended up being needed even with raw input. Meh. Shouldn't cause any issues though.

[nr1995]

I'm sure you already know this,
but at higher-than-60 framerates,
the repeat rate of moving your little selection square across your inventory is too fast,
and the repeat rate delay is far less, meaning it's too easy to overshoot.

[emoose]

Changing the Sleep(3) call at 0x97B83B to Sleep(90) (bio4.exe+0x57B83C 03 -> 5A) seems to affect the 120Hz audio somewhat, kinda helps with the weird repeating/reverb that it has, but there's still definitely a difference between 60 & 120, mainly seems volume related somehow?

AFAIK the loop that holds that Sleep call is what handles audio in the game, seems to be running in a seperate thread & runs at whatever your CPU can handle though, changing variableframerate didn't seem to affect speed of it at that loop at all, but somehow changing the value for that Sleep call does have an effect on the sound, weird.

Fortunately the game seems to use XAudio / XACT3 for audio here so no awful CRI stuff to deal with, but looks like they do have a ton of code for processing the audio themselves before handing it to XAudio (which itself is pretty different to the GC/PS2/VR code), unfortunately haven't found much related to framerate there yet though :/

[Danixxxxx]

Wow, although it still has its bugs, playing through the game with 120FPS + raw input feels AMAZING. So smooth and responsive! No longer do I think the Wii version has the best controls 😅 If you guys manage to perfect both these tweaks, imo the gameplay would be superior to even the RE5 PC port(which doesn't have as nice mouse turning as yours). Here are some bugs that I noticed on a 120FPS Professional playthrough, hopefully there's something that helps:

-certain enemies get stuck in animation loop

Animation.Loop.Bug.mp4

-audio glitches such as multiplied audio(this happens with 60fps too) or skipping if too fast

Audio.Bug.mp4

-some attacks do less damage than on 30/60fps(these guys always die with 3 lanterns)

Less.Damage.Bug.mp4

-harder to run up elevations like these

Momentum.Bug.mp4

-some enemy attacks do more damage than on 30/60fps

More.Damage.Bug.mp4

-game is slow-motion in more demanding areas

Slow.Motion.Bug.mp4

-character/environment models don't pop up correctly during cutscenes and such

Cinematics.Bug.mp4

Even with these issues, this is still my new preferred way to play, it's just so fluid... I'm hoping you guys manage to work out all the kinks eventually 🙏

[emoose]

Here's a build of 1.7.5 with the framelimiter & aim speed fixes added, seems to still work as it did before:
re4_tweaks-1.7.5-framerateFix.zip

[Danixxxxx]

Here's a build of 1.7.5 with the framelimiter & aim speed fixes added, seems to still work as it did before: re4_tweaks-1.7.5-framerateFix.zip

Is there one without console? 🥺

[Bass-junkie]

i have a rtx 3080 / 12900 ks @ 5.4 ghz and using the above fix with hd project and the re 4 tweaks

i run 1440p 270 hz gsync and was geting out of sync shooting .

now its working 270 hz perfectly sao far even when they throw dynomight no fps slow downs !

ill keep this updated

[Bass-junkie]

any updates ?

[nipkownix]

@emoose, got a weird enemy loop here:

They get stuck trying to get bombs to throw. Happens after a couple of successful throws at 240 fps.

The function looping is em10_R1_R305Bomber (but other normal bomber enemies are looping too, as posted earlier in the comments).

It loops here, because a1->pWeapon_610 is always null:

This section in the same func is supposed to set up pWeapon:

It works fine at first, but then em10MakeWeapon starts returning 0 all the time.
Apparently, what is actually failing is cManager_cEm_::createBack inside SetWeapon, called inside em10MakeWeapon. Haven't figured out why ::createBack fails though.

[emoose]

Haven't figured out why ::createBack fails though.

Maybe it's not clearing up older EmWep instances properly, and ends up hitting Em limit, is the count shown inside Em Manager near the max limit shown there?
We can increase that limit by editing CNS/Cons data (that stuff was brought up on the discord recently too), maybe it's just an issue of higher FPS meaning more EmWep instances are spawned at a single time, making it hit the maximum - or it could be an issue with them not being disposed properly.

[nipkownix]

Oh shoot, you're exactly right! The Em limit is reached very quickly:

Goes from 20 Ems or so to 60 after they throw bombs about 3 times.

Really seems like they're not being disposed properly.

[emoose]

Ah 60 is the default CNS value baked into the EXE afaik, might mean the room doesn't have a CNS value defined for it - maybe worth testing with that default value increased (int at 0xBFC044 in 1.1.0) and see if it still ends up breaking or not (changing that to something like 180 before loading in should be fine, seen other rooms using that at least)

Maybe there's some ceiling it reaches where it would start to dispose of them, but ends up hitting that tiny 60 limit before it. (E: seems not, just keeps increasing, weird)

Still kinda strange that increased framerate makes so many of them spawn though, maybe there's an issue with it running that em10MakeWeapon code in multiple frames when it should have only really been ran once.

[Bass-junkie]

an y updates on this ? any updates on no fps lock fixes on higher fps

[nr1995]

It's been 18 months.
Has progress been made on this?
Is there another mainline release coming ever?

[Bass-junkie]

same the last update i can play@360 hz @ 360 fps ona14900 ks and rtx 4090 with minmal bugs just fastswitching invintory and some audio bugs but shes like 90 % perfect

[nr1995]

same the last update i can play@360 hz @ 360 fps ona14900 ks and rtx 4090 with minmal bugs just fastswitching invintory and some audio bugs but shes like 90 % perfect

What is the lastest FPS unlock build?