-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Counters: Tighten tolerances on framelimiter #3785
Conversation
Smooths out frame pace and keeps average framerate closer to target.
Fixes graphics issues in some games
|
||
// If any integer value of milliseconds exists, sleep it off. | ||
// Prior comments suggested that 1-2 ms sleeps were inaccurate on some OSes; | ||
// further testing suggests instead that this was utter bullshit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is true and might compromise accuracy a bit - it's worth running a test without sleep at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be that those games don't hit the condition for a sleep?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I run at well above the frame cap in those games. I get about 70fps in SotC, so there should be about 3.334ms (maybe 2.5ms, my calculation may have been off) my CPU is waiting every frame.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good approach, but I would go even further and make it something like msec - 3
or even 5. The threshold has to be pretty big or else you'll always risk people losing time on those e.g. due to running on a laptop battery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I don't recommend people run the emulator on a laptop and if they do they should be using high performance mode and not running off battery (that's a really dumb idea :P) I'm honestly not concerned about people crazy enough to do that, it will still be head over shoulders above master (which was 1ms buffer)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that should be good enough as a starting point and could be revisited in the future if it's ever needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using a gaming laptop plugged in with high performance mode and it does improve significantly on specific games, u could stare blindly at squeezing an extra 5%-10%.
Another change has just been pushed that should (sometimes) tighten this up even further. |
Latest PR (8aaae36) |
Has anyone checked Linux? RTSS is not available but at least to make sure stability is still good? |
Examples when i change the msec if (msec > 1): (original PR) @RedPanda4552
|
Just tested on Linux x86 with EGL and GTK2, with a few Kingdom Hearts games (KH1, KH2, Re:CoM). Seems stable. |
Discovered this article thanks to a forum user: https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ We may need to play with Win10 2004 release. Sounds like they are changing how thread sleeping will behave and sleep(1) is going to be a LOT more latent than ever before, if this is right. |
Update on the above: multiple testers have disclosed they did their tests on 2004 and had positive results. I am comfortable with where this is but more testing is always welcome. Up to everyone else. |
Frame pacing did seem quite a bit better in a few games I tried, although Xenosaga is one that still kind of gives weird readings. |
Smooths out frame pace and keeps average framerate closer to target.
Comparing PCSX2's old framelimiter with RTSS showed there was room for improvement. Frametimes regularly would jump up and down in various situations. This PR smooths out frame pace substantially (easily visible in RTSS) and, drum roll please, may appease the input lag folks for a time. We'll find out.
Extensive user tests required; some vsync functions were shuffled around, and this was tested on a high performance system. We should test low end systems, and a wide variety of games to make sure there are no outlier games that needed the old behavior for some reason.
Shoutout to Refraction for greasing the wheels and helping with the various vsync aspects.
Before (above) and after (below) of Xenosaga Ep. 1 save point inside the Elsa:
