search

c0dycode / MGRR-Mods

Simple Mod-Overlay for Metal Gear Rising Revengeance
MIT License
5 stars 0 forks source link

Suggestion: Please fix the framerate limiter #3

Open Zaphero1 opened 3 years ago

Zaphero1 commented 3 years ago

For those who don't know an unstable frame limiter is a longstanding issue with inhouse Platinum Games PC ports that can be found in Wonderful 101, Transformers Devastation, a small amount in Bayonetta, and MGRR where the framerate starts at a lower framerate that what it's supposed to be targetting, usually 59 fps like with MGRR, and then the target jumps up and down getting more and more erratic as time goes by due to an error in floating point precision. Silent fixed this on Wonderful 101, detailing the issue and how they did it here with the source of the fix being open. https://cookieplmonster.github.io/2020/05/16/silentpatch-wonderful-101/ https://github.com/CookiePLMonster/SilentPatchW101

Can this be implemented as a fix here? There is not patch for this and given that this post was made a year ago, it doesn't look like one is coming.

c0dycode commented 3 years ago

That's very interesting. I've never noticed this issue before. I'll certainly check this out and see when I can implement these :)

c0dycode commented 3 years ago

Okay, I think this is pretty close to what it should ™️ do. It still sometimes happens that it dips to 59 or spikes to 61 - though I'm not sure if that also happens with Silents patch, as I do not own any of those games.

I also couldn't 1:1 port this over, so I had to do it slightly different - I've never worked on this kind of thing and my math-brain is pretty small, so this might not be perfect :P

This should ™️ also prevent the issue of fps dropping after longer periods of time.

See if this works as you'd expect 👍

FrameLimiter Fix Test.zip

Zaphero1 commented 3 years ago

Ah thank you! Yeah you're right, it fixes the hard part. No matter the uptime the frame limiter doesn't become more erratic, but it looks like the sleep code in the rendering cycle isn't disabled yet. I tried using SKIM of Special K to keep an eye on the framerate and tried using its embedded disable sleep cycles option and it fixed those dips to 59 and spikes to 61. So that sleep cycle disable part from Silent's patch doesn't seem to be working yet.

c0dycode commented 3 years ago

Hm, it's patching the same one that Silent patches. I'll see if disabling one of the other couple sleep-calls does the job then. 🤔

c0dycode commented 3 years ago

Looks like it is/was not related to a/the sleep-function. I suspect it is/was another rounding/calculation issue.

It appears that with this one it very rarely happens anymore. I've only gotten it once to spike to 61 and that was after increasing the "Jump Height" to max and jumping up very high. That caused the fps to drop slightly and after landing it spiked to 61 for a brief moment.

Might just be the engine freaking out a bit 🤔 No idea yet. Been testing with simulated uptime of 20 days.

I've also added another change to make the menu 60 instead of 30 FPS. Hopefully this improves things on your end aswell. FrameLimiter Fix Test #2.zip

Zaphero1 commented 3 years ago

Wait it's possible to do that? Wow yeah looks like the animation isn't even sped up in the 60fps menus. Great job! I do have to say though that it seems like limit is a bit more taxing, in places I could get 60 with the previous one through SKIM I get around 57-58 and when it's at 60 in combat it still seems to have issues with frame pacing enough to make it visually stutter? In terms of that external program, SKIM doesn't seem to be adding much this time around; it can't read it for displaying specs interestingly enough. Not like it should be expected for it to work with yet another program even if it did before, but yeah.

Not sure how helpful this is, but I've been using the 64bit version of it here. https://github.com/Kaldaien/TSF/releases/tag/tsfix_0105

Since I'm a bit all over the place with my testing there with info that may not be helpful, I feel I should ask what would you like me to test.

c0dycode commented 3 years ago

Okay, at this point I'm either still doing something wrong or this is as good as it gets with this method.

If I set the framelimit via RTSS it's very stable - pretty much a straight line. If I use this one it appears to be as "stable" as the screenshot in Silent's blogpost.

I honestly don't really know how I could improve that any further though :/ FrameLimiter Fix Test #3.zip