Add FixSlowdown to FRAME RATE settings, support for above 60FPS

[emoose]

Made the fix from #23 (comment) use signatures, seems to work fine across 1.0.6/1.0.6 debug/1.1.0 😃

I noticed one thing while testing, seems maxFrameTime var shouldn't be kept at 31, looks like it depends on the display / internal framerate (not sure which yet), so for now it's set to (variableFramerate / 2) + 1

This means going below half of the variableFramerate setting will still result in slowdown though... hopefully can find some way to detect if user is in the new-game event & only apply this maxFrameTime stuff in that case (or detect if user is in gameplay & make it disable this instead), so we can get rid of all slowdown during gameplay. (the commented EvtMgr stuff might help with this in future, so I left that in for now)

I've only added INI setting for it, wasn't sure about adding to UI since I don't know how easily this can be reversed :/

This should probably be tested out a lot before merging, have only really tried out the beginning new-game section with it myself so far... will probably try a 100Hz run over the weekend, if anyone has a >60Hz monitor please give it a try!

E: here's a build + INI for it, INI has been setup to enable it: winmm_fps-slowdown-fix.zip

To use >60FPS, edit your Documents\My Games\Capcom\RE4\config.ini file, and change variableframerate to your desired framerate, and run the game - if it still doesn't work, try setting vsync to 0 in config.ini.

[Keith94]

I played at 144 FPS up until the Hunnigan cutscene. Didn't encounter any issues so far.

[nipkownix]

Nice! I'll test the stuff that triggers the usual FPS-related bugs, like this one I recorded on release:

https://www.youtube.com/watch?v=PZEGNNjldqE

geez, has it been this long already?!

Edit: Grenade issue seems to still be here:

2021-12-03.09-38-14.mp4

[emoose]

Huh I've never seen that grenade problem before, that was with 60FPS? Wonder what could cause that.

I have tried the new build along with resolution 1920 1080 144; however, game is still running at 60 Hz (in fullscreen). Can't really get Special K to work either for some reason...

Ah yeah same happens here, I only really tested this in windowed mode, but looks like fullscreen always uses 60Hz mode for some reason, will need to try looking into what handles that.

E: might have found the cause for that, seems 0x9391E0 (1.1.0) goes through each D3DDISPLAYMODE returned by D3D9, but seems to only check for 60Hz ones there, so anything not 60hz will get skipped over...
Easiest way to fix that would probably be hooking ConfigReadINI so we can capture the refresh-rate from there, and then patch the insn at 0x93924F with the refresh rate.

Unfortunately I can't test this out since it looks like my 100Hz mode doesn't show up in the D3DDISPLAYMODE list that D3D9 returns for some reason (guess it's something to do with being a custom resolution)

If someone with a actual 120/144Hz monitor wants to test, open bio4.exe with hex editor, go to 0x538651, and change the 3C to your display rate in hex (for 120Hz use 78, for 144Hz use 90 144 won't work because it'll get treated as negative >.>), hopefully with that + config.ini updated the game should be able to use that display mode in full screen.

[emoose]

Added some hooks that should allow non-60Hz fullscreen modes hopefully, like mentioned above I haven't been able to test it properly myself though, but think it should work.

Build+INI here: winmm_fps-slowdown-fix-v2.zip

Make sure the resolution line in config.ini is set with the refresh rate you want to use, and hopefully with that the game should be able to use that rate in fullscreen.

E: also just noticed 0x93A850 (1.1.0) seems to setup shadow resolution based on INI shadowQuality setting, wonder if changing the values in there could improve things at all.

[nipkownix]

Huh I've never seen that grenade problem before, that was with 60FPS? Wonder what could cause that.

The first video (from 2014) was at 59 fps. Yeah, even one frame less than 60 caused issues.
The other video was at 144 fps.

Added some hooks that should allow non-60Hz fullscreen modes hopefully, like mentioned above I haven't been able to test it properly myself though, but think it should work.

Oh, nice! This should fix the black screen issue people have when their monitors don't have 60 hz as an option.

Edit: latest build is crashing inside gameMainLoop, at this instruction:

[Keith94]

Great finds thanks!! I'll try it out when I get home and get back to you.

[emoose]

Edit: latest build is crashing inside gameMainLoop, at this instruction:

That's with the build I just posted? What game ver is that? I did test against 1.1.0/1.0.6 before pushing, not sure why it'd be changing gameMainLoop.
Does disabling FixDisplayMode get rid of it? Maybe the sig is matching some other piece of code somewhere.

[nipkownix]

Hmm, tried disabling both options, but the game still crashes. There might be something wrong with my game? I'm using .exe ver 1.1.0

Edit: oh, it was raz0r's trainer crashing the game. No idea why.

Grenade issue is happening consistently here:

The game also freezes when trying to quit, for some reason:

This is at 144 fps. Maybe that's too high?

Also, might as well mention this here as well: that issue about invisible item in the inventory with RaiseInventoryAlloc enabled is happening here, but only with the builds you posted in this PR:

[emoose]

Ah looks like it freezes on quit for me too with 60FPS, looks like it's the FixSlowdown fix that causes that, hmm
(E: seems to happen even with the reimplemented vanilla code from #23 (comment) - guess there must be something missing there... E2: huh, the code seems to be exiting properly, WinMain returns to __tmainCRTStartup, which runs exit() & __cexit(), yet game window remains, don't know what could be preventing it from closing, strange...)

Does the inventory issue go away if you disable both FixSlowdown & FixDisplayMode?

[DustyCrumpet]

Here's a few issues:

1. Audio issues with footsteps.

Audio.mp4

2. Backwards turning is too fast.

Backwards+Turning.mp4

3. Striker spews out shells after firing / TMP reload sound repeats.

Striker.+.TMP.mp4

4. Backing out of the inventory can cause the game to remain paused (Health bars still animate).

Inventory.Hang.mp4

5. Water and Leon's headturning may be too fast.

Water.+.Headturn.mp4

60FPS footage was recorded with FixSlowdown = false and variableframerate 60.

[emoose]

Here's a few issues:

Thanks for giving it a try, I'd guess some of these like backwards turning/head turn/water are probably also wrong speed at 60FPS too, probably need to find a way to adjust those to match with 30FPS speed, like how nipkownix's 60FPS item falling fixes were done.

That striker bug is crazy lol, haven't seen anything like that before, guess that's something animation related, but since it's also playing sounds for the shells too maybe it'll be easier to track down than the rifle animation issue.

[nipkownix]

Does the inventory issue go away if you disable both FixSlowdown & FixDisplayMode?

It doesn't, actually.

This makes no sense.

Release/Debug build from master: no inventory issue.
Your build with both new options disabled: inventory issue shows.

However, people on nexus were having this exact same issue with the latest release, while it works fine for me.

Cursed bug

Edit: I just built your branch myself and the bug isn't showing anymore. Even more cursed now.

Edit2: uh, so, now it doesn't even show with your builds anymore.

Some memory corruption must be happening randomly.

[emoose]

Does the inventory issue go away if you disable both FixSlowdown & FixDisplayMode?

It doesn't, actually.

This makes no sense.

Release/Debug build from master: no inventory issue. Your build with both new options disabled: inventory issue shows.

However, people on nexus were having this exact same issue with the latest release, while it works fine for me.

Cursed bug

Damn... guessing it's probably some weird memory issue, maybe something gets corrupt under certain conditions, I hate bugs like that >.<

For me the inventory seems fine with this build, same with your one on nexus too :/

I'll try looking over the stuff we patched to redirect the buffer soon, maybe something was left out somewhere.

(wonder if maybe g_MemPool_SubScreen/g_MemPool_SubScreen2 initial values could be affecting anything, maybe those should be memset to 0 first...)

E: btw just to be sure, you're using the same resolution/fullscreen mode/etc between tests right? Was thinking maybe screen res changes how much of those buffer is filled, not sure about that though.

[nipkownix]

E: btw just to be sure, you're using the same resolution/fullscreen mode/etc between tests right? Was thinking maybe screen res changes how much of those buffer is filled, not sure about that though.

Yep, same settings and starting a new game on every test.

[Keith94]

Build+INI here: winmm_fps-slowdown-fix-v2.zip

Can confirm that FixDisplayMode = true fixes the refresh rate issue, so the game defaults to whatever I set in Windows. :)

However the game is unstable in this build. Alt+Tabbing and opening the video settings in game will result in crash.

[emoose]

Looks like the striker shell issue is something to do with the call to MotionCheckCrossFrame inside cObjStriker::moveFire, some reason at 144Hz that's always returning true, which makes it call into cObjStriker::setCartridge to spawn shells everywhere.

Not sure why MotionCheckCrossFrame is broken, probably some float it's checking is off. I've been trying to map out the MOTION_INFO structs etc, mostly have the field types mapped out but haven't named much yet. IDB is here if anyone wants to have a look at it: pc-1.1.0_enum - Copy.7z.zip

E: hmm, think it's an issue inside MotionSequenceCtrl, there it's doing something with the *((float *)pG + 0x1C) deltaTime value that we updated for >60Hz.

Problem is somewhere around the a1d = *((float *)pG + 0x1C) * a1->speed_C0 + a1->field_B8; part I think
Seems it's setting the frame counter to the last frame # for the animation (which would let MotionCheckCrossFrame finish up), but then v9 = v8 - *((float *)pG + 0x1C); line removes the deltaTime value from the frame count for some reason, so it'll never actually see that the animation finished playing all the frames, weird.
E: If I nop the insn that removed the deltaTime from it then it does stop from spewing shells, but also makes weapon invisible for some reason... maybe this is just a symptom and the issue is somewhere else :/

Thinking about it, maybe this is what's causing issue with grenades too, game maybe doesn't realize animation has ended so it ends up like that, hmm

E2: oh wait wtf, the shell issue happens for me even with variableframerate 60 in config.ini, probably not framerate related then, guess it's something to do with the deltaTime calculation or something :/

[nipkownix]

E2: oh wait wtf, the shell issue happens for me even with variableframerate 60 in config.ini, probably not framerate related then, guess it's something to do with the deltaTime calculation or something :/

Yep, I was about to post that.
Pretty wild bug.. looks hilarious! I even got to change the direction of the shells and everything.

[emoose]

Hmm, might have an idea what's happening:

MotionSequenceCtrl:

      v4 = (flags & 4) == 0;
      animNumFrames_ = a1->numFrames_BC;
      newFrameNum = *((float *)pG + 0x1C) * a1->speed_C0 + a1->field_B8;
      newFrameNum_ = newFrameNum;
      a1->field_B8 = newFrameNum;
      if ( v4 )
      {
        animNumFrames__ = (double)animNumFrames_;
        if ( animNumFrames__ <= newFrameNum_ )
        {
          v9 = animNumFrames__ - *((float *)pG + 0x1C);
          a1->field_42 = 4;
          a1->field_B8 = v9;
        }
      }
      else
      {
        v7 = (double)animNumFrames_;
        if ( v7 <= newFrameNum_ )
        {
          a1->field_42 = 1;
          a1->field_B8 = newFrameNum_ - v7;
        }
      }
    }
    

In that code it seems to be using the deltaTime (*((float *)pG + 0x1C)) multiplied by anims speed to find the new frame num, then it checks that frame num against the total number of frames to make sure it can show it, if new frame num is larger than frame count, then it'll try removing value of deltaTime from it (I guess this would keep removing deltaTime from it each frame until new frame num is valid)

Problem is with our FixSlowdown setting deltaTime isn't fixed any more, and probably varies a lot each frame, so it'd probably end up overshooting the frame num every time.

Wonder if changing that so it just uses animNumFrames__ value if it's above it might help at all, wouldn't be surprised if that ends up breaking other stuff though.

E: aha yep, nopping the insn that subtracts deltaTime seems to fix it 😄 no doubt something else is probably broken though.
Insn is at 0x65FE82 in 1.1.0.
Sadly doesn't seem to help with grenades though, maybe that's something to do with another part of that function.

[emoose]

Here's a build of that commit:
winmm_fps-slowdown-fix-v3.zip

Only difference I've noticed is the striker shell bug is fixed, looks like grenades are still broken, and game still won't quit properly :/
I haven't tested it that much yet though, maybe it'd help with some other issues too.

E: seems grenade explosion is triggered by cSubWep::moveNormal function, that also makes use of deltaTime for a similar thing with subtraction too, hmm...

New IDB with the cSubWep stuff labelled: pc-1.1.0_enum - Copy.7z.zip
I noticed there's a cSubWep::bounce func called by cSubWep::addSpeed too, guess something could be going wrong in there.

E: it's looking like cSubWep::moveNormal might be responsible, seems in that func it has a framesRemaining var in field_360, if framesRemaining is greater than 0 then it subtracts some based on deltaTime and calls cSubWep::addSpeed code, but if it's below 0 it just calls cSubWep::addSpeed - only if it's exactly 0 will it run the last part that runs cSubWep::explode, and thanks to the unsteady deltaTime it won't actually get to exactly 0.

Not really sure if this can be patched that easily, maybe hooking it and setting to 0 if it's below might work though.

[emoose]

Alright seem to have something working, should fix grenades + striker reloading, haven't tested it that much yet though so not sure if it might break anything else.

Build+INI: winmm_fps-slowdown-fix-v4.zip

[nipkownix]

Nice! Your fixes are working nicely here!
The only obvious problems I've noticed are random freezes. Sometimes it freezes when loading a save, for some reason.
Also, I've noticed the aim speed was inconsistent. Apparently it got slower with high frame rates. I've pushed a fix that should make everything more consistent.
This might also be the reason some people say this version of the game has a lower sensitivity when playing with a controller. I haven't tested if these changes affect controllers too, but they probably do (?)

Edit: another freeze issue I've noticed:

The game freezes if the windows UAC prompt appears on screen.
Easily reproducible by: open the game -> open cheat engine -> press yes on UAC prompt -> game frozen Edit2: this turned out to be my fault.

[DustyCrumpet]

Here's a build of that commit: winmm_fps-slowdown-fix-v3.zip

Only difference I've noticed is the striker shell bug is fixed, looks like grenades are still broken, and game still won't quit properly :/ I haven't tested it that much yet though, maybe it'd help with some other issues too.

This build fixes the TMP reload sound too, but breaks several death animations (even at 60fps with FixSlowdown = true):

Death.animations.mp4

Also another bug that happens with the original build (second jump on the church bridge):

Church.jump.mp4

[nipkownix]

About FixDisplayMode, I'd suggest maybe getting the refresh rate from Window's current resolution instead of reading it from config.ini. This would solve people's black screen issues without having to change anything inside config.ini.

A custom refresh rate could then be set from winmm.ini, which is easier to find and allows evrything to be configured from one place, + we can change it using the ImGui menu, I guess.

[SupahDrivah1234]

Hi, I've been having trouble trying to get the Steam version of Resident Evil 4 running on my PC for the past year or so since my laptop (a Lenovo Legion 7i) has no selectable refresh rate other than 144Hz and CRU isn't working for me. The game would only open in a small black window with audible sound but no video.

This fix managed to at least fix the video, for which I'm grateful, but I hadn't walked two feet before trying to check settings in the options menu and it crashes to desktop.

As far as I can tell, it's only the primary pause/options menu. Is there a way to fix this?

[nipkownix]

Made the changes to FixDisplayMode I mentioned earlier, and implemented it in the current master. I wanted to get this fix in re4_tweaks before the HD project releases, since a large number of people with non-60Hz displays will likely run into this issue when trying RE4 for the first time with the HD project.

@SupahDrivah1234, I believe you're the same person I replied to on Steam, but here's a build with just the black screen fix and nothing else from this PR, since the other stuff is probably what is crashing your game:
Bin32.zip

[Mister-Curious]

about that grenade suspension problem; was this ever resolved? I recently noticed this too on a room I was working on, but managed to fix it by editing the EAT file. Maybe that issue you see is simply some bad EAT in the room you were in (looks like r109 if I am not mistaken). If the issue is still present, I can edit the r109 and send it over for testing.

[SupahDrivah1234]

Made the changes to FixDisplayMode I mentioned earlier, and implemented it in the current master. I wanted to get this fix in re4_tweaks before the HD project releases, since a large number of people with non-60Hz displays will likely run into this issue when trying RE4 for the first time with the HD project.

@SupahDrivah1234, I believe you're the same person I replied to on Steam, but here's a build with just the black screen fix and nothing else from this PR, since the other stuff is probably what is crashing your game: Bin32.zip

I think you did reply to me on Steam, yes.

Unfortunately, even with a clean install of RE4 this new build didn't work. I'm facing the same issue of being unable to open the options menu without crashing to desktop.

[nipkownix]

Hmm, this new test build has some logging that might help us understand the issue a little better:
winmm.zip

To the get log, create a folder named "CrashDumps" in re4's bin32 folder, near the .exe file.
Then, have the game crash as usual, and two files should be generated inside that new folder.
Upload them here so we can have a look.

about that grenade suspension problem; was this ever resolved? I recently noticed this too on a room I was working on, but managed to fix it by editing the EAT file. Maybe that issue you see is simply some bad EAT in the room you were in (looks like r109 if I am not mistaken). If the issue is still present, I can edit the r109 and send it over for testing.

I think it was solved with the last commit.
What are EAT files, btw? Just curious.

[nipkownix]

@emoose Got a crash log + minidump of the issue @SupahDrivah1234 is having. Used the stuff from the branch I mentioned in #38.

bio4.exe.20220119145646.zip

Looks like the FixDisplayMode crash when trying to open the options menu is caused by the game failing to read a list of resolutions, if I'm not mistaken. I haven't looked too deep into it yet, but it seems the entire list is just missing when that option is enabled. Either that or the pointer for it is wrong?

Edit: Got it to not crash by making it just not read the resolution list:

No idea what could be wrong with this list though. Maybe the game is making a list of 60hz resolutions -only-? And we end up with an empty list if no 60hz mode is present?

[emoose]

Maybe the game is making a list of 60hz resolutions -only-? And we end up with an empty list if no 60hz mode is present?

That reminded me of this comment in one of the commits here: 28c2701#diff-59bafca88011950dfe128dac79f2499e832dde20dc1ee96cdf788919734f3961R170

Could be that's related, I'm not sure if your FixDisplayMode touches the func hooked there, might be worth looking into.
E: Unfortunately didn't comment the addr for what gets hooked there, but think it might be either 0x9391E0 or 0x953480 (1.1.0)

E2: ah I should have looked at your commits first, looks like that does already hook that func, hmm... guess there's probably other 60Hz checks around too, maybe in one of the addrs above.

[nipkownix]

Hmm, my FixDisplayMode is the exact same as yours, the only difference being that I get the refresh rate from Windows instead of getting it from the ini file.

[emoose]

I think that fix only hooks the EnumAdapterModes stuff in 0x9391E0, but looks like the 0x953480 func that calls EnumAdapterModes also has some weird 60 checks inside it, maybe that's what makes the res list. (E: does seem to get called just a little bit before the part that caused exception too)

Some weird checks in that for v12.Width - 800 > 9680 || v12.Height - 600 > 9880 as well, don't really get what it's trying to do there, guess it's a strange way of doing minimum/maximum on the width/height (limiting it to between 800x600 - 10480x10480 I think, good to know for when we want to run RE4 in 10K I guess :)

[nipkownix]

Oh, there's another func calling EnumAdapterModes? I'll check that out.

Edit: You're right on the money again, @emoose. Hooking that section fixed the crash! Thank you!

Some weird checks in that for v12.Width - 800 > 9680 || v12.Height - 600 > 9880 as well, don't really get what it's trying to do there, guess it's a strange way of doing minimum/maximum on the width/height (limiting it to between 800x600 - 10480x10480 I think, good to know for when we want to run RE4 in 10K I guess :)

Oh no! But what about the people runing RTX 12080s in a distante future?! We better add an option to uncap this silly limit.

[nipkownix]

@SupahDrivah1234, let me know if this build resolves your issue:
winmm.zip

[Mister-Curious]

@nipkownix Glad to hear it was resolved. EAT files handle projectile collision data and has the same structure as SAT which handles player and enemy collision data. With no EAT there is no ground for the grenade to bounce off.

[SupahDrivah1234]

@SupahDrivah1234, let me know if this build resolves your issue: winmm.zip

That worked! thank you so much for your help.

[emoose]

BTW the PCGW page for RE4 currently links to the old winmm_fps-slowdown-fix-v2.zip build in this PR as part of fixes for non-60Hz screens: https://www.pcgamingwiki.com/wiki/Resident_Evil_4_Ultimate_HD_Edition#No_video_on_monitors_with_high_refresh_rates_.2F_Game_runs_at_incorrect_refresh_rate

Maybe it's worth making a proper release with the new fixes, if you feel all the new changes after 1.6 are stable enough.

[nipkownix]

Ah, thanks for the heads up. I'll probably make a new release today, then. I just want to address #40 before making the release.

Edit: new release is up and I've updated the PCGW stuff.

[emoose]

Hmm, so the main animation problems seemed to be caused by delta-time varying between different frames... I wonder if locking it to 90/120FPS frametime would work better, wouldn't help with the slowdown issue at all, but it'd give benefit of increased framerate at least (as long as user can maintain it), I guess it'd probably help show what things need framerate fixes too (wind/water/etc).

Maybe I'll make a new PR soon with something like that, since this PR draft is mostly to do with slowdown.

[nipkownix]

Maybe I'll make a new PR soon with something like that, since this PR draft is mostly to do with slowdown.

Nice. Sounds like a good idea to me.

[emoose]

Huh seems it's easier than I thought, just need to overwrite the double it uses for limiting framerate from 0.166666... to 1/framerate, so 0.011111... for 90FPS, (double is at 0xB1D180 in 1.1.0), then make sure your config.ini variableframerate is set to 90, and with those game looks like it runs at 90 fine - would probably work with 120 fine as well, but my monitor doesn't support that so can't test it myself - not sure if 144 would work that well since it's not a multiple of 30.

I imagine there's probably lots of things that need timing fixed similar to the 60FPS fixes though, maybe running at higher framerate will make it easier to spot those.

If anyone wants to try it out here's some builds, feel free to report issues in this PR for now:
re4_tweaks1.7.2_90fps.zip
re4_tweaks1.7.2_120fps.zip
re4_tweaks1.7.2_144fps.zip

Edit your Documents\My Games\Capcom\RE4\config.ini first and set resolution line to end with 90/120/144, and set variableframerate to 90/120/144, and edit re4_tweaks INI and change IgnoreFPSWarning to true (forgot to do that in the included INI...)

(btw, seems re4_tweaks is ignoring the IgnoreFPSWarning ini setting now for some reason? always shows the messagebox about framerate being changed, had to edit it with CE instead...)
E: building from src seems to have fixed that, weird.

[nipkownix]

(btw, seems re4_tweaks is ignoring the IgnoreFPSWarning ini setting now for some reason? always shows the messagebox about framerate being changed, had to edit it with CE instead...)
E: building from src seems to have fixed that, weird.

Could have been because I moved IgnoreFPSWarning to another section in the .ini file?

[emoose]

Could have been because I moved IgnoreFPSWarning to another section in the .ini file?

Ah that might be it, looks like my INI had it in the new section tho, so guess I was probably using a build from before 1.7.2 somehow (maybe built from an older commit at some point)

In case anyones wondering, the builds I posted are from the latest commit, just added a line of code to patch the frametime in.

[Keith94]

Not sure if it's a known issue, but I tried re4_tweaks1.7.2_144fps.zip and the inputs in the menu are twice as fast, so it often skips two menu options with one press.

[emoose]

Posted a new PR with improved framelimiter fix here: #50

If anyone wants to test greater-than-60 FPS please let us know of any issues there!