À big advantage of Retroarch is that it can use vrr even on windowed mode. Vast majority of other retro emulators require fullscreen
2 Likes
Hello there. I’m glad this topic is active because it’s been bugging me for years now. I’m using computer monitors (VRR-capable Alienware 240Hz, different Viewsonic 120/240Hz models) and I always get the same results with RetroArch:
120/240 Hz physical refresh rate + VSync ON + VSync Swap Interval AUTO + Sync to Exact OFF = perfect frame pacing (no micro-stuttering) on near-60Hz games.
120/240 Hz physical refresh rate + VSync ON + VSync Swap Interval AUTO + Sync to Exact ON = bad frame pacing (micro-stuttering) on near-60Hz games.
This is on an VRR-capable system on GNU/Linux:
- AdaptiveSync LabWC Wayland compositor
- VRR capable monitors.
- FreeSync is active on the monitor and AdaptiveSync is active on the Wayland compositor
- AdaptiveSync is reported working by wlr-randr which is the modern equivalent to xrandr on Wayland-based systems.
The whole chain is correct.
Native games have perfect frame pacing (even 35 fps games on 120/240Hz video modes, like OpenTyrian, Chocolate Doom, etc) and, most interestingly, standalone MAME does have it too for games with all kinds of exotic framerates like MK, Caveman Ninja, Demon’s World… everything is absolutely perfect as expected with regards to VRR/AdaptiveSync, except in RetroArch (and dosbox-stanging… but that’s a different story).
For reference, MAME has to be set up like this:
Video options:
Window Mode - Off
Synchronized Refresh - Off
Wait Vertical Sync - Off
Advanced options:
Throttle - On
Adjust speed to match refresh rate - Off
Low latency - Off
I know this is NOT about standalone MAME, but since standalone MAME does VRR/FreeSync correctly, I want to give all the possible information.
As things are, on RetroArch, perfect frame pacing with “Sync to Exact” is only possible with severe compromises, but it may give valuable information:
- If Audio Sync is disabled, Sync to Exact provides perfect frame pacing in every core and game, but there are occasional (and expected) audio cracklings.
- Setting a 60Hz physical refresh rate on the monitor (instead of 120/240Hz, which are usually the recommended / default rates for these monitors), it’s also possible to have good frame pacing with Sync to Exact, but since VSYNC is also needed, this defeats the purpose and introduces input lag (60Hz + VSync will always introduce input lag no matter what).
I made the vrr code and it’s just setting as monitor refresh what the core is giving as its timing (also bypassing the timing_skew for sound DRC, and a fast forward hack/fix).
I see some things I didn’t touch (or were added later? not sure) you can try changing.
It’s forcing swap interval 1 when exact sync is enabled, you could try removing that condition.
There’s a limit at swap 4 there, I’m not sure why.
I’m still on my now old 120hz gsync chip inside monitor so I can’t test high refresh and multiples yet.
Maybe there’s a need to bypass the timing_skew or bring the swap multiplier into the vrr_runloop later.
2 Likes
I’m getting good pacing on a 240hz monitor myself. At least for the games that i know they have locked frame rates. I don’t consider games with unlocked frame rates a good test for this.
I also always make sure RetroArch is on a high performance profile. I remember getting sound issues on Bsnes when i didn’t do that.
1 Like
Hi, Tatsuya! Thanks for taking the time to participate in this thread.
I have tried removing this condition, also this swap 4 limit, but at that point I realized something:
I think what some of us are seeing here is an effect of emulators having variable frame times.
That’s why, having working VRR setups, we only see this subtle effect in RetroArch and not in native games: as I said, even OpenTyrian, Taradino or Chocolate Doom, which are 35 FPS games, have good frame pacing. In Ship of Harkinian, I can set framerate to 54 FPS or some other crazy exotic value and it looks perfectly smooth.
But on emulation, it’s different once we leave the classic “activate vsync and synchronize emulation to that” paradigm: you let the emulator impose the framerate, the frame times won’t be steady and the monitor won’t be able to keep up with these variable frame times.
I have found more information this old thead on the BlurBusters forum. It’s administrator is the most knowledgeable person in the world for this kind of problems, and has contributed with libretro in the past. From there:
For proper fluidity on VRR displays, your refresh cycles is controlled by the exact timing of the pageflip. So…when you’re in VSYNC OFF mode or VRR mode please use microsecond clocks for timing your framebuffer flips in your emulator source code!. This will reduce microstutter issues for software-triggered display refresh cycles (which is what GSYNC and FreeSync essentially is) especially for strongly fixed-Hz content such as videos and emulators. Basically, when programming for a VRR display, you’re now doing the equivalent of software-based VSYNC ON that’s lower lag than waiting for a monitor’s next fixed refresh cycle (for a non-VRR display). To successfully display fixed-Hz material (emulators, videos, etc) in a way that is as microstutter-free as true VSYNC ON, but without lag of VSYNC ON, you have to have really pristine framepacing accuracy. Do not use uncompensated millisecond-accurate timers, you may have to intentionally do a micro-busywait loop (a few tens or hundreds microseconds) within your timer event, to intentionally re-align your next frame buffer pageflip to a more exact interval since the last framebuffer flip […]
@GemaH The effect we’re talking about (essentially “movement is not as smooth with Sync to Exact ON as it is with classic VSYNC only”) is very, very subtle, and I dare to say most people won’t even notice it unless purposely looking at it, and even so, I bet it depends on how each person perceives movement “continuity”.
I am glad you don’t see it, but I think the problem is there on any monitor because apparently it has do do with how emulation itself works (unless somehow compensated for, as apparently standalone MAME does).
1 Like
Oh believe me, if it’s there i can see it. I’m very sensitive of it. And if you could see my posting history in most other forums, you would see countless posts about PC games having “microstutters”. I’m talking about a couple of frames lost every now and then, it drives me crazy. Which is exactly why i got a VRR display in the first place.
I can assure you i don’t have this issue in MOST cores. Though i still have frame pacing issues in Dolphin, when i play 30fps games but that’s a Dolphin issue, not a RA issue.
I can share my RA cfg if you want in case there’s something different. But i feel like the difference lies elsewhere. Maybe it’s the GPU/Drivers. I use Nvidia and i always have VSync-ON via the driver. I also make sure the “power management mode” is at “high performance” when i run RA.
Maybe it’s Windows? I still use Windows 10, i have no idea how this performs on Linux or Windows 11.
Honestly i want to help because i know how annoying this issue can be. But saying “you have the issue. you just can’t see it” is a bit condescending. I have said it in the past myself for other people but only in simpler cases. RetroArch is a chain of many things so you can never be sure what other people are getting from it.
@GemaH I am truly sorry if I sounded condescending here. I didn’t mean it. I have read you countless times around here, and I know you are quite an advanced RetroArch user, but since the issue is so subtle, I thought it could be a perception difference. I think from what you told me, that probably you don’t have this issue: NVidia tech (NVidia drivers are closed source so we can’t really know) may be in the way and somehow doing it’s own thing which is not what my graphics stack based on AMD Radeon graphics based around an opensource compositor and MESA 3D Vulkan/GL implementation does.
No worries.
Yes, having a different GPU/drivers could be a factor. Though i have no idea how the options are in AMD GPUs.
I assume you have those options correct? Is there anything there that relates to giving your GPU full power at all times and not letting it “sleep” when nearly idle? RetroArch and emulators don’t use much of the GPU most of the time so there’s a chance it jumps from idle to not idle and changing this state randomly could cause microstutters like this.
I also assume you are on a Desktop and not on a power-saving adjusted Laptop or something like that.
Can’t say much else when it comes to your system outside RetroArch. But here is my Retroarch.cfg if you want to compare it with your’s. Oh, and i don’t use RTSS with RetroArch.
This is for a 240hz monitor. Adjust the refresh rate accordingly.
Could you also suggest me a scenario that i can try myself? Like a specific game and core? To make sure we are on the same page.
I have vimdiff-ed your config and mine, and I don’t see any relevant differences in the video synchronization.
As for GPU energy management, on modern GNU/Linux I can simply do:
Set high performance mode:
echo high | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level
Verify:
cat /sys/class/drm/card0/device/power_dpm_force_performance_level
Watch the GPU running at highest freq unconditionally:
cat /sys/class/drm/card0/device/hwmon/hwmon*/freq1_input
…But that doesn’t make any difference for this issue.
That’s unfortunate. Since you tried the same cfg as mine i can’t offer anything else since i know nothing about Linux.
Do you have any Windows based PC you could try this on? This way you could confirm the issue is with RA on Linux specifically, if that’s the case.
@Tatsuya79 A frontend that works correctly with VRR/AdaptiveSync monitors without closed-source drivers is JGRF
Talking with it’s author, he helped me to understand it’s screen refresh algorithm. It goes like this:
// Divide the core framerate by the monitor refresh
runframes = (corefps / screenfps);
// Collect the remainder of the same division operation
collector += (corefps / screenfps) - runframes;
// When sufficient remainder has been collected, run an extra frame
if (collector >= 1.0) {
++runframes;
collector -= 1.0;
}
for (int i = 0; i < runframes; ++i)
exec_frame();
video_render(runframes); // re-render if runframes is non-zero
video_swapbuffers(); // swap whatever is in the video buffer every frame
It results on a constant VFreq of 120 Hz reported by the monitor and perfect movement with ~60 Hz emulated systems under JGRF. It wasn’t designed towards VRR, but it works for ~60Hz content on a 120 Hz monitor perfectly. It’s similar to having in RA: VSYNC ON, Swap Period AUTO/2 (on a 120Hz display), and Sync to Exact OFF. Except for one difference: JGRF always swaps buffers, thus resulting in these constant 120 Hz VFreq on the monitor OSD. Maybe swapping unconditionally even with Exact Sync is ON could help? That wouldn’t be VRR anymore, of course… That would be VSYNC + Swap Period…
So in the end, I suspect that the problem lies in emulation frame times. And as the BlurBusters founder says, RetroArch should re-align each next frame buffer pageflip to a more exact interval since the last framebuffer flip.
Sorry, I don’t have a Windows machine. And for ideological reasons (which I am proud of) I would NEVER have one or even use one for anything. But I really appreciate your willing to help. The author of this thread however said it was seeing the same on Windows, so there’s that.
yes it is very subtle and you have to look for other clues. Eg in SNES game Tiny Toons Buster Busts Loose, one would think that everything is fine and motion is smooth.
However if you look at the burst bar, with VRR on it flickers ultra fast, however on non-Vrr it flickers at a slower rate. Without this I would not have noticed.
That’s it. Fast-flickering animations are perfect for seeing this issue. Perfect example.
Wait… Which one is correct you think?
I just tested Tiny Toons on SNES and the burst bar flickers at the same ultra fast rate in both my 240hz VRR screen (with sync to contend enabled) and the regular 60hz TV (with sync to contend disabled).
Also, the scrolling in both scenarios is the same. In normal speed it’s not 100% smooth but i’m sure that’s intended because the scrolling becomes smooth at running speed. I think this is the same behavior as Super Mario World.
The fast flickering is also 100% even. I don’t see anything that looks uneven.
I tested the same game outside RetroArch on Ares (which should be 100% accurate) on the 240hz screen and i get the same result. Very fast flickering on the bar, slightly stuttery motion when walking, smooth motion when running.
Pretty sure your non-VRR result is not how the game is supposed to be.
The ultra fast flicker
it will flicker like this on non-VRR displays (1:19 mark), though this could also be due to recording software issues. It should be double speed really. So this is incorrect.
but result would be closer to this. Mobile phone records at 60 hz and it does not display even ultra flicker but monitor does.
It also works via Switchres on a CRT VGA in 120 hz mode
Depends also on the emulator. On windowed mode it flickers slower on all emulators, as Ares and Snes9x require fullscreen. Retroarch supports windowed VRR too. If you try the game on Finalburn for example,it flickers slow in fullscreen too as emulator has not implemented VRR yet.
On Mesen you have to enable exclusive full screen mode for it to work.
I’m a little confused tbh 
I can’t tell the way it flickers on your second video. Is the first video supposed to be slower than the real SNES?
I tested with Ares in Fullscreen btw.
yes, the first video is slower. you are not supposed to spot the color switch between white and purple. Though somet It is similar to the character flicker shadow in Samurai Showdown 2, though there at least you have the character select screen background animation smoothness to see if vrr is active.
now I noticed. First video sometimes does flicker slower and it confused me. I guess YouTube player synchro plays games too.
found a better video that is older and there it flickers slower regardless. Eg at 3.00m.
That last video you posted is 30fps. It cannot display a rapid effect like that properly. Also, you must mean yellow and purple, not white.
You say you are not supposed to see the flicker, are you sure about that? Can you confirm the effect on a real SNES and CRT? I had the game back in the day but i can’t remember. But why would they make a flicker effect in the first place if you couldn’t see it?
The game runs natively at 60fps, i assume half of them is yellow and other half is purple. That’s fast but it should also be very noticeable to the human eye. If you can’t see it then something must be wrong.
If it doesn’t supposed to flicker in a noticeably manner, then every emulator on every screen i personally tried displays is wrong. Not just RetroArch.
Ok i also did another test to make sure the effect is correct in RetroArch:
Just press “P” and then tap “K” to advance one frame. Every time you tap “K” once, you should see a different color. 1 frame yellow, 1 frame purple. This is the correct effect and that’s what i’m getting in RetroArch using “sync to content” on a 240hz VRR display. It’s a perfect 1 color change every frame.
Edit: Hmmm, the frame advance method might not be a reliable way to see this because even if i turn sync to content OFF and i can clearly see the uneven flickering, the frame advance still shows the same result. So the bad sync only happens when the game is actually running and is not paused (in my case).
But it still confirms that it’s 30 frames one color and 30 frames the other. Which should be very noticeable to the eye on the real SNES too.