What's the best FPS limiter these days?

[Sparky]

Vsync is not used on my gaming PC anymore

in that case, I'd use in-game framerate caps if any, as anything else comes with a latency penalty.

[Chief Blur Buster]

Try it, and then come back to me and tell me "it stutters."

It doesn't. And I should know. I'm the hugest pixel whore the universe has ever seen. If you think YOU care about that stuff, you have NO idea.

I think both of you are right.

Allow me to explain: vsync, semantics, engine/drivers/os, and mouse limitations.

1. VSYNC. The frame skip will not show if VSYNC is OFF (full screen mode). Basically, this is the situation you're using the FPS limiter to create a low-latency VSYNC ON.

2. Semantics: A single frame skip does not look like a real stutter, but some of us (myself included) can detect a single frameskip, but only by keyboard, not mouse. And only for super fast motion.

3. Engine/Drivers/OS. For the VSYNC ON situation, frameskip may or may not happen depending on wheher its behaving as double buffering (blocking page flip) or triple buffering (nonblocking page flip).
....A good FPS limiter that cooperates well with double-buffered VSYNC ON, may be causing a late input readout and render before next refresh cycle, to reduce latency button-to-pixels. In this case, it is possible no frame skip will occur due to the framerate ending up exactly matching refresh rate because of the throttling effect of VSYNC ON (blocking page flips) depending on how the capping algorithm is programmed. The frame skip occurs only with non-blocking page flips (e.g. Behaving like defacto triple buffering -- Windows compositing and windowed mode will show the frame skip, e.g. VSYNC OFF + Windowed Mode behaves like triple-buffered VSYNC ON, due to Windows compositing. Page flips are non-blocking but there is no tearing as the Windows compositing buffer is the third buffer in front of everything running on the screen.). Exact behavior will also vary between games, depending on how the frame capping algorithm interacts with blocking page flip behaviors.

4. Mouse: A single frameskip at high refresh rates is so faint and so occasional at such close differentials, that natural mouse imperfections hides it (even at 1000Hz). But I DO see the single frameskip when strafing left/right by keyboard at close range. Or any "nintendo-NES-perfect platformer panning motion" situations. Where motion is perfect fluidity.

Yes -- I confirm, I do see the single-frameskip-every-X-seconds effect.
Yes -- I confirm, the frameskip effect CAN disappear.

I see the occasional frame skip /certain/ situations, and definitely not by mouse movement (for me, at least), and not with full screen VSYNC OFF.

Easiest way to demonstrate is a game that can switch to windowed mode and full screen mode on the fly:
If you go to full screen mode (VSYNC OFF) there is no single frame skip, and instead, I get a very faint (jittery) tearline that slowly rolls either upwards or downwards cycling the screen height once every X seconds -- instead of the frameskip every X seconds which shows up again when I go back into windowed mode. Switching to windowed mode, the tearing disappears but the frameskip reappears. This frame skip appear/disappear effect occurs with Source Engine games with an fps_max configured slightly below refresh rate by a fraction of a Hz.

Not all frame rate limiter algorithms will behave the same.

[RealNC]

The main thing here though is that NVidia's limiter is complete bollocks. It adds two frames of input lag instead of one, and has tearing at the very bottom of the screen, and after that bottom tear line, it's 1 frame of input lag for the remaining 3% of the screen height. So basically you get 2 frames of lag. RTSS meanwhile gives you 1 frame of lag for the whole screen.

If you set the control flag to "0x00000040 PS_FRAMERATE_LIMITER_2_CONTROL_FORCE_OFF" in order to tell the driver to not enable adaptive vsync behind your back, then it doesn't cap anywhere near the target frame rate. Capping to 144FPS for example caps to 154.x FPS instead. Which is completely 100% useless.

So even if we ignore the issue where 0.05FPS difference will stutter or not and just want to cap spot-on to the refresh rate, RTSS is still superior. It keeps input lag at 1 frame at most, and doesn't tear since vsync is kept on. With nvidia's limiter, you get two frames of lag, and a nice tear line at the very bottom. Which incidentally matches gsync's behavior when you hit the refresh rate... I wonder if nvidia is switching on their limiter in that case and is why gsync users see that behavior...

[Glide]

Seems like the latest RTSS update added support for fractional steps.

Added power user oriented profile setting, allowing you to customize framerate denominator for the built-in framerate limiter. The denominator can be customized to adjust the limit in fractional steps (e.g. denominator 10 to adjust the limit in 1/10 FPS steps)

I have no idea how you are supposed to use this feature though.
There's nothing in the GUI and manually editing the config just limits to whole frames.

[RealNC]

The author is unwilling to make this configurable through the GUI.

You need to edit the profile file (I edited the "Profiles\Global" file) and put this in it:

Code: Select all

[Framerate]
Limit=1199
LimitDenominator=10

This limits to 119.9FPS. Or:

Code: Select all

[Framerate]
Limit=11995
LimitDenominator=100

This is for 119.95FPS. "LimitDenominator" determines the amount of decimals. So 100 is the most useful one. Unfortunately, this breaks the GUI, but as said, the author is unwilling to change that, unfortunately.

I could have fixed it myself, but well, these are the joys of closed source software :-/

[Glide]

Well that doesn't surprise me.
Unwinder also intentionally broke compatibility with the Steam Overlay in recent versions too, to try and force Valve to white-list it.

As for this feature: it doesn't work as well as I would have liked.
With V-Sync off I can get it dialed in to mostly stay in one place if I'm just looking at a wall, but when actually playing a game the tear line seems to jump up and down a bit from that position, so no forcing the tearing to occur at the top/bottom of a frame and stay there.

Looks and feels really nice when it works though; a mostly tear and stutter-free image with very low latency.
Makes me hope for the possibility of a G-Sync OLED, since LCD panels have regressed in contrast from the 5000:1 (native) display that I have.

[Chief Blur Buster]

Using a large blanking interval gives a bigger amplitude for jittery tearlines. If you use VT1350, there's 270 of hidden scanlines (blanking intnerval) between the previous & next refresh cycles. That's plenty of space for jittering tearlines to keep them offscreen.

Problem is, if you're programming a FPS limiter to steer the location of the tearline (e.g. RasterStatus.ScanLine API call), you don't know how big the blanking interval is unless you use high-precision timers (microseconds) to benchmark the time between (RasterStatus.ScanLine == 1079) and (RasterStatus.ScanLine == 0) for a 1080p display, in order to calculate how large the blanking interval is, then divide by two, then try to time the framebuffer page flip roughly that "X" time after RasterStatus.ScanLine == 1079 .... so you have a hidden tearline exactly in the middle of the blanking interval. And obviously, the bigger the blanking interval, the more room the hidden tearline has to jitter all over the place before becoming visible. (Larger Vertical Totals -- using larger Vertical Sync, or larger Vertical Front Porch or or larger Vertical Back Porch, of Custom Timings & Resolution Utilities such as PowerStrip, NVIDIA Control Panel, ToastyX Custom Resolution Utility, etc)

Steering the location of a tearline using 100% software means is very challenging, but precise raster timing has been done for decades -- e.g. Commodore 64 Raster Interrupts and Atari 2600 TIA tricks -- And even with 3Dfx cards and modern GPUs (Microsoft exposes RasterStatus.ScanLine for raster polling, but you can't easily query for the size of the vertical blanking interval....sigh).

I know Aaron Hightower successfully did tearline-steering for low-latency VSYNC OFF (that looks like VSYNC ON) with the 3Dfx-powered arcade game San Francisco Rush.

An exercise for an expert open source programmer programming FPS limiters that has ability to algorithmically steer the location of the tearline (in combination with larger blanking intervals for easier VSYNC OFF tearline hiding)...

It obviously should be a toggleable option, since tear-line steering affects whatever latency is on whatever part of the screen -- on both sides of the tearline. The image below the tearline has 1 frame less latency than the image below the tearline. And it is not even as simple as that -- in extreme framerate situations (e.g. 300fps @ 120Hz) there can be multiple tearlines per refresh cycles. In the situation that there is two tearlines on the same refresh cycle, the top segment is 2 frames behind the bottom segment, and the middle segment (between the two tearlines in the same refresh cycle) is right in between the two in terms of latency. So late-rendering pipelines timed precisely to steer the tear-line off the bottom edge (e.g. tear-line steering algorithms) is simply a compromise of creating a much lower-latency VSYNC ON, but not fully as lagless as VSYNC OFF.

Oftentimes it's simpler to create other low-lag framerate limiting algorithms. But the above is the "perfect" lowest-possible-lag VSYNC ON (timing the latest possible GPU frame rendering, with the freshest possible input read, to complete rendering just before the blanking interval, and then immediately flip once current nearly-complete refresh cycle is now complete. Essentially de-facto steering the tearline right off the bottom edge of the screen, or above top edge of screen).

[RealNC]

As for this feature: it doesn't work as well as I would have liked.
With V-Sync off I can get it dialed in to mostly stay in one place if I'm just looking at a wall, but when actually playing a game the tear line seems to jump up and down a bit from that position, so no forcing the tearing to occur at the top/bottom of a frame and stay there.

Yeah, that's not gonna work. The use case here is to use vsync while being able to configure the frame limit closer to the refresh rate without having to use CRU.