-
-
Notifications
You must be signed in to change notification settings - Fork 771
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
Frameskipping on high refresh rate monitors (with workaround) #827
Comments
How does this behave with current dev builds? I made some changes to this area recently but don't have a high refresh rate monitor to test on. |
It works if I enable sync with video! I'm on 120Hz and it doesn't speedup or frameskip anymore. |
If you're also using sync to audio, how big is your audio buffer? I noticed that if it's too big there are some frame skipping issues even on a 60fps monitor. |
Indeed, there is some occasional frame skipping and audio crackling I couldn't reproduce/notice earlier (on the default 1536 samples). Increasing the buffer size reduces the frame skipping, but there's still a lot of audio crackling. I'm not sure if it could be of any help, but the definitive way I got around this issue was by using the libretro core and enabling "Sync to Exact Content Framerate" on RetroArch's Frame Throttle menu. It still works on the 0.7.0 8d0bf2a build (latest one from the updater). |
For me, I'm using a 144 Hz G-SYNC monitor and try to play the games with the native framerate and only "Sync to Audio" enabled. I also recently downloaded a dev build from a few days ago after having one from the end of January. |
Can confirm that it is an issue for me as well in version 0.8.3 under windows 10. Don't know about my other linux box as a comparison to find out if it is windows specific. Only way I could get it to run was to turn refresh rate down to 60 as I saw in another thread. As a reference, my monitor with freesync shows an instability of frame rates from around 40 to 144 extremely fast that I think causes the issue. Taking freesync off doesn't solve it; it just confirms the fps issues and displays tearing because of it. Turning it down to 60 refresh made fps stable. Maybe what the op said, capping it at 60 fps, solves the issue as well. I realize this has been an issue for some time by the start of the bug report, but I can give some log, trace, or however it is bugs are filed for this program since describing the issue and a workaround does not help as much as that. |
On my 144 Hz G-SYNC compatible monitor I'm having trouble reproducing this. Regarding sync to audio, you want to keep the buffer size as low as possible. If you turn it too low the game will start running slow and crackling, but if you turn it too high you'll get audio lag and weird frame rate issues. If you're on a high framerate monitor and can't keep the audio setting below maybe 1024 you should try turning on both. When I tried reproducing this today it just seemed smooth no matter how I tweaked it however. This was on stock 0.8.4 too. @LimitCrown can you retest? |
The instability still exists for me on 0.8.4. I will say I find it a little better, but I do not know it it might be a placebo. I am testing windowsx64 version as a reference. I will add that, in my case, I find that disabling sync to audio to make the game play at multiple hundreds fps makes the refresh rate of my monitor fluctuate between 120 and 144. I concluded that my computer not able to produce those fps is not the problem. They still fluctuate from around 40 to 144 refresh rate when the game is capped at around 59.7. I discovered that capping the game to 144 fps would smoothens the game in my case while writing this post if it helps. Any other fps besides the refresh rate makes it a little bit choppy from the instability in refresh rates. 60 fps with 60 refresh rate still has solves the issue. |
Can you please retest on the latest dev build? I made some changes to how it handles sync last night. |
I didn't test the dev build, but the problem still exists for 0.9.1 which was released after the date of that build. |
I just pushed a timing tweak for this that may decrease the effect you're seeing. Can you please confirm on latest dev build? |
I'm able to reproduce this to some extent by changing these settings from default on my Nvidia Control Panel:
However, this may just be the placebo effect and I was already having it. That said, now that I can see it I'll see what I can do about fixing it. |
Weirdly, it looks like the builds I make on my Windows machine that I use for testing do not exhibit this behavior (or not as badly at least), which is frustrating because it makes it harder to test. That may be why I was unable to reproduce it before. |
I attempted to fix this for 0.10.0, but ran into enough trouble that I've delayed it until 0.10.1 in the interest of finally releasing 0.10.0. |
d8687d3 fixed this issue for a while, but it had to be modified and no longer works. However, I've found that limiting the framerate to 60fps (tested with Nvidia Inspector, but should work with Radeon Settings as well) fixes this issue with no additional settings needed. Fast forwarding is unaffected.
mGBA version: 0.7-4713-a7fb446
Tested on Windows 10 x64, i7-4770k and GTX 1070.
Monitor: BenQ XL2420Z@120Hz
The text was updated successfully, but these errors were encountered: