Skip to content
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

Open
marcellocordeiro opened this issue Jul 25, 2017 · 14 comments
Open
Labels
port:Qt Affects the Qt version (the standard desktop version)
Milestone

Comments

@marcellocordeiro
Copy link

marcellocordeiro commented Jul 25, 2017

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

@waddlesplash waddlesplash added the port:Qt Affects the Qt version (the standard desktop version) label Aug 6, 2017
@endrift
Copy link
Member

endrift commented Jun 6, 2019

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.

@marcellocordeiro
Copy link
Author

It works if I enable sync with video! I'm on 120Hz and it doesn't speedup or frameskip anymore.

@endrift
Copy link
Member

endrift commented Jun 6, 2019

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.

@marcellocordeiro
Copy link
Author

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).

@LimitCrown
Copy link

LimitCrown commented Jun 6, 2019

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.
I've noticed that the framerate tends to be uneven in a sort of way. If I try increasing the audio buffer setting, the framerate of the video ends up looking less smooth. Setting it to 768 samples results in the smoothest output of the choices, but it still looks a bit uneven and setting it to 512 inhibits the speed of the game.
There has also been some weird pauses in-game, but I don't know whether this is due to the recent dev build. It hasn't occurred beforehand.

@endrift endrift added this to the mGBA 0.9.0 milestone Jan 28, 2020
@youandmy
Copy link

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.

@endrift
Copy link
Member

endrift commented Mar 12, 2021

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?

@endrift endrift added the blocked:needs retest Needs a retest to confirm if it's fixed label Mar 12, 2021
@endrift endrift modified the milestones: mGBA 0.9.0, mGBA 0.9.1 Mar 16, 2021
@youandmy
Copy link

youandmy commented Mar 21, 2021

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.
Edit: 144 fps speeds the game up, but it stabilizes refresh rates at 144 which makes the games smooth.

@endrift
Copy link
Member

endrift commented Apr 13, 2021

Can you please retest on the latest dev build? I made some changes to how it handles sync last night.

@endrift endrift modified the milestones: mGBA 0.9.1, mGBA 0.9.2 Apr 19, 2021
@youandmy
Copy link

youandmy commented May 2, 2021

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.

@endrift
Copy link
Member

endrift commented Jun 20, 2021

I just pushed a timing tweak for this that may decrease the effect you're seeing. Can you please confirm on latest dev build?

@endrift endrift modified the milestones: mGBA 0.9.2, mGBA 0.9.3 Jul 11, 2021
@endrift
Copy link
Member

endrift commented Aug 4, 2021

I'm able to reproduce this to some extent by changing these settings from default on my Nvidia Control Panel:

  • Power management mode: Prefer maximum performance
  • Texture filtering - Anisotropic sample optimization: On
  • Texture filtering - Quality: High performance

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.

@endrift
Copy link
Member

endrift commented Aug 5, 2021

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.

@endrift endrift modified the milestones: mGBA 0.9.3, mGBA 0.10.0 Dec 26, 2021
@endrift
Copy link
Member

endrift commented Oct 12, 2022

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.

@endrift endrift modified the milestones: mGBA 0.10.0, mGBA 0.10.1 Oct 12, 2022
@endrift endrift removed the blocked:needs retest Needs a retest to confirm if it's fixed label Dec 16, 2022
@endrift endrift removed this from the mGBA 0.10.1 milestone Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
port:Qt Affects the Qt version (the standard desktop version)
Projects
None yet
Development

No branches or pull requests

5 participants