Blur Busters Forums

Sparky wrote:If the game has an in game limiter, using it will be the lowest latency option. RTSS has one more frame of buffering when compared to an in game limiter, which in some cases can reduce stutter. That's a tradeoff judgment you'll have to make on a case by case basis. As far as I'm aware, RTSS is the best external framerate available.

RTSS does not appear to have any frame buffering going on. The frame pacing is better because it's more accurate. The input lag difference between RTSS and most in-game limiters is due to in-game limiters being able to reduce input lag more than RTSS can.

RealNC wrote:

Sparky wrote:If the game has an in game limiter, using it will be the lowest latency option. RTSS has one more frame of buffering when compared to an in game limiter, which in some cases can reduce stutter. That's a tradeoff judgment you'll have to make on a case by case basis. As far as I'm aware, RTSS is the best external framerate available.

RTSS does not appear to have any frame buffering going on. The frame pacing is better because it's more accurate. The input lag difference between RTSS and most in-game limiters is due to in-game limiters being able to reduce input lag more than RTSS can.

RTSS limits framerate by backpressuring the game engine. That backpressure causes one frame to be buffered(as the game engine is waiting on RTSS after it's done working on a frame), which both increases latency by one frame, and smooths out CPU frame time variance.

Sparky wrote:

RealNC wrote:

Sparky wrote:If the game has an in game limiter, using it will be the lowest latency option. RTSS has one more frame of buffering when compared to an in game limiter, which in some cases can reduce stutter. That's a tradeoff judgment you'll have to make on a case by case basis. As far as I'm aware, RTSS is the best external framerate available.

RTSS does not appear to have any frame buffering going on. The frame pacing is better because it's more accurate. The input lag difference between RTSS and most in-game limiters is due to in-game limiters being able to reduce input lag more than RTSS can.

RTSS limits framerate by backpressuring the game engine. That backpressure causes one frame to be buffered(as the game engine is waiting on RTSS after it's done working on a frame), which both increases latency by one frame, and smooths out CPU frame time variance.

And sometimes decreases overall latency.

This is done by eliminating a worse latency side effect, such as backpressuring against VSYNC ON (2-3 frames) or against a VRR maximum (2-3 frames, too). In exchange for a little forced delay onto the game engine, creates a large reduction of buffer pile-up at the graphics drivers level.

To use RTSS to reduce GSYNC lag, see GSYNC 101: 240Hz Input Lag Tests
To use RTSS to reduce VSYNC ON lag, see HOWTO: Low-Lag VSYNC ON

In 2013-2014, I was the world's first person (outside NVIDIA) to discover, and demonstrate, the sudden-momentary-lag-increase phenomenon of frame rates hitting against a GSYNC refresh rate maximum, via GSYNC Preview #2 (old article).

Further input lag reductions are possible via predictive frame capping (delaying a game engine's next input read to right before rendering & delivery before next VSYNC; for tighter delivery of a frame during VSYNC ON). This is a feature I've suggested on Guru3D forums to the RTSS developer (please "Like" that post). This will allow RTSS to further decrease VSYNC ON latency for software that has the vast majority of frametimes far less than a refresh cycle. This makes it desirable to delay input read & rendering until right before the VSYNC interval. Such games can continue to run perfectly smooth and stutterfree, but have even less VSYNC ON lag on fixed-Hz monitors, than is currently achievable via the tricks in HOWTO: Low-Lag VSYNC ON.

This is what GeDoSaTo does, as "predictive frame rate capping to reduce input lag":


This is a feature that definitely should be added to RTSS to achieve further lag reductions.

Yes, to be clear it only increases latency relative to an in game cap.

So with GSYNC, it is better to just use ingame limiters majority of the time because of the lower input lag? RTSS's superior framepacing does not matter because GSYNC's frame delivery already solves this problem?

Also when I mentioned CSGO being all over the place, I mean that it's a few frames lower than what I set, and it fluctuates by a small amount, whereas RTSS is a solid, consistent cap.

I've noticed the that issue in CS:GO myself, but I have yet to figure out if the RTSS FPS counter is misreading the limit, or the CS:GO FPS counter is, because CS:GO shows what I set, and RTSS shows an offset.

Either way, it doesn't really matter, in-game is still lower latency (and yes G-SYNC smooths frametime variances out; can't do anything about frametime spikes though), and a couple frames at high Hz is virtually indistinguishable.

Yes -- the "single frame drop" type stutters are rendered invisible by GSYNC.

That's why GSYNC/FreeSync is friendly with less-precise frame capping.

Lower-lag capping thus, becomes more important than capping frame rate precision in this case.

Sparky wrote:RTSS limits framerate by backpressuring the game engine. That backpressure causes one frame to be buffered(as the game engine is waiting on RTSS after it's done working on a frame), which both increases latency by one frame, and smooths out CPU frame time variance.

If the game takes 10ms to render a frame (100FPS), you have 10ms worth of added latency. If you cap to 90FPS with RTSS, that's 11.1ms of added latency. RTSS will give you the natural frame latency of your target frame rate. It will not add anything to it. In this case, you get 1.1ms (the difference between 100FPS and 90FPS), and that's not even nearly "one frame". One frame here would mean 22.2ms of frame latency, not 11.1.

Please keep in mind: With RTSS, you will get the natural frame latency of your target frame rate. No frames are buffered, no latency added.

(As chief said, latency is decreased, in fact, even with RTSS.)

What I advocate here is getting rid of the "RTSS adds extra latency compared to in-game limiters" statement. Instead, it should be "RTSS reduces input lag, but in-game limiters can reduce it even further."

RealNC wrote:

Sparky wrote:RTSS limits framerate by backpressuring the game engine. That backpressure causes one frame to be buffered(as the game engine is waiting on RTSS after it's done working on a frame), which both increases latency by one frame, and smooths out CPU frame time variance.

If the game takes 10ms to render a frame (100FPS), you have 10ms worth of added latency. If you cap to 90FPS with RTSS, that's 11.1ms of added latency. RTSS will give you the natural frame latency of your target frame rate. It will not add anything to it. In this case, you get 1.1ms (the difference between 100FPS and 90FPS), and that's not even nearly "one frame". One frame here would mean 22.2ms of frame latency, not 11.1.

Please keep in mind: With RTSS, you will get the natural frame latency of your target frame rate. No frames are buffered, no latency added.

(As chief said, latency is decreased, in fact, even with RTSS.)

What I advocate here is getting rid of the "RTSS adds extra latency compared to in-game limiters" statement. Instead, it should be "RTSS reduces input lag, but in-game limiters can reduce it even further."

There's a reason I use the phrasing I do. There are two kinds of latency responsible for most of the delay in the game/graphics pipeline. Latency caused by calculation time, and latency caused by buffering. There's not much you can do about latency caused by calculation time, aside from reducing settings or getting faster hardware. The thing we're talking about right now is latency caused by buffering. The thing that causes buffering latency is the bottleneck, and the bottleneck will fill up all the buffers before it, and none of the buffers after it. The game engine can rate limit frames just before it gathers user input, leaving only calculation time afterwards. RTSS has to make the game wait on it, increasing the amount of time the previous step of the pipeline to 1 second divided by framerate.

Basically, latency starts at zero, and only goes up. You count the latency you have remaining, not what you eliminated. If you have a traffic jam, you count the delay as compared to a clear road, not a worse traffic jam.

Yes, v-sync causes a lot of lag, and RTSS can mitigate that, however it is still a cause of latency, as, RTSS will still increase latency by 1/framerate when compared to an in game framerate cap at the same framerate, even with v-sync off.

This is where I disagree. RTSS will not increase latency. It just won't DECREASE it as much as an in-game limiter.

Your "road" analogy doesn't apply as given, because if you add something to a traffic jam that doesn't make it worse, but instead makes it slightly better, it's just hugely unfair so claim that it made things worse :-/

In fact, this leads to people not using it at all, preferring the raw traffic jam, because of the claim that things are worse otherwise. In our case, that means if a game does not have an in-game limiter, then it's better to not cap the frame rate at all instead of capping with RTSS, because "RTSS increases input lag", which is wrong (and objectively so.)

What you are saying:

RTSS: Bad.
In-game limiter: Good.

What I am saying:

Uncapped: Bad.
RTSS: Good.
In-game limiter: Even better.