Blur Busters Forums

I was under the impression that Freesync would "just work" with emulators (at least MAME and Retroarch) but, according to RTSS's frame time graph, that doesn't seem to be the case. In MAME for example, if I try the game Galaxian with RTSS's frame time graph enabled, there will be consistent, slight variations, despite Freesync being enabled. This is with all vsync options disabled in MAME and throttle enabled. However, if I input the refresh rate in RTSS that MAME reports upon boot: 60.606061, then the graph will be flat.

I've noticed the same thing in Retroarch with various cores like beetle-saturn, genesisplusgx, mupen and mesen. I have Retroarch set up to use Freesync, but the RTSS frame time graph will show consistent, slight variations. I've been able to achieve a flat graph in those cores by inputting a 59.94 limit in RTSS.

In RPCS3 for at least one game, using a 59.94 limit was need for a flat graph.

In Dolphin I needed to use a 59.97 limit for a flat graph.

Curiously, trying a game in Xenia didn't need any special limit for a flat graph.

I've been using Freesync in the aforementioned emulators for awhile now and didn't notice perceivable stutter, so I'm not sure if RTSS is measuring frame time variance that I've not noticed or if it's not functioning properly for this use case. I'm using an Alienware aw2521hf 240hz monitor. RTSS is version 7.3.1.

Freesync has nothing to do with producing flat graphs. What it does is, no matter how the graph looks, it will show each frame close to whatever time the graph's value indicates.

Also, a "flat graph" doesn't give you anything. Some variation is normal and has no effect on anything, especially with freesync. A flat graph is only beneficial when not using freesync and trying to instead use "low latency vsync," where exact frame timing is important due to having a fixed refresh rate. With freesync, exact frame timing is not important at all.

VRR is software-timed refresh cycles.

Emulator framerate caps are not usually as accurate as RTSS framerate caps. RTSS is the backup cap for imperfect emulator frame pacing.

For maximum precision, you can combine both emulator cap & RTSS cap, where emulator cap imperfections is backstopped by RTSS framerate caps.

Combining emulator cap + RTSS cap is fine for VRR. In this case, you want to be careful that RTSS cap does not interfere with the emulator -- some emulators prefer RTSS cap slightly higher than emulator cap, rather than lower -- but it varies by emulator.

So what you are doing is a good workaround for imperfect software framepacing (since VRR is software-timed refresh cycles), creating a backup framerate cap for imperfect in-game framerate caps, when your priority is motion fluidity (e.g. emulators)

Since in-game/in-emulator capping is lower lag -- you will get the lowest lag by making sure your RTSS backup framerate cap is ever slightly higher than the in-game/in-emulator cap (preferably fractionally like 0.001 difference). But some software may also require RTSS to be same or below the actual framerate output.