Poor mans G-Sync/Freesync

I remember an old thread over at nogripracing where people discussed how to achieve smooth gameplay with minimal input lag in rFactor and what gave the best results was Vsync ON and cap the framerate to your monitors frequency -1. But this would give you a skipped frame once every second so it turned most people off.
Now with new technology we can cap the framerate at a much higher precision (down to 3 decimal points) which in theory will eliminate this problem.

I came across a thread browsing the guru3d forums last night and a guy named RealNC made a great guide on the subject.

Credit goes to RealNC over at guru3d.com
Here is the actual thread https://forums.guru3d.com/threads/the-truth-about-pre-rendering-0.365860/page-12#post-5380262
I highly recommend reading the entire thread for more insight.

You want to use RTSS (Riva Tuner Statistics Server) to cap your framerate as it's the only tool (that I know of) that have sub ms accuracy.

Ok here we go!

---------------------------------------------------------------------------------------------------------------------------------

Vsync does not actually cap the frame rate. This is a popular misconception about vsync. What it does is syncing the output of new frames to the monitor's "vblank" signal (the point between the monitor having finished scanning out the current frame and is preparing to scan out the next.) The frame rate not exceeding the refresh rate is just a side effect of that. There's no actual frame capping involved.

Because there is no frame cap, the game is preparing new frames as fast as it can. Once all possible frame buffers and all pre-render queues have been filled, only then will the game stop queuing more frames to be displayed. That means when all these buffered and queued frames are displayed later on, they're based on old input. Meaning input lag.

Setting pre-rendered frames to 1 means less queued work is waiting to be processed. The game stops trying to output more frames sooner. Meaning you get less input lag. However, this doesn't help with queued frames that have already been rendered but have accumulated in the output buffers. You still get more input lag that needed.

You can fix this issue by using a frame cap that's set at almost the exact same value as your refresh rate. Something like 0.01FPS below refresh rate works fine (RTSS is accurate enough to allow for this kind of frame limiter accuracy.) Note that "0.01" is just a ballpark number. Anything between 0.007 and 0.015 or so should work fine. Too low and the trick doesn't work anymore, too high and you get repeated frames that result in "hiccups".

Please note that all this is for vsync. You don't need to do any of this when using G-Sync or FreeSync. For those two sync methods, just cap to 3FPS below your refresh rate and you're done! Also note that all this also doesn't apply to vsync off. This guide really, really is just for non-gsync, non-freesync monitors with vsync enabled. (Or if you for some reason disabled gsync/freesync on your monitor and want to use plain vsync.)

Step 1: Find out your real refresh rate

Nope, your real refresh rate is in the majority of cases not 60 nor 59. It's usually fractional. Most monitors use 59.94Hz for "60Hz" and 119.982Hz for "120Hz". You can detect your real refresh rate on these sites:

http://www.testufo.com/#test=refreshrate
https://www.vsynctester.com

Let the test run for a while (around 2 or 3 minutes should be enough.) Do not run both tests at the same time. Do not have any background tasks running.

If both sites give you results very close to each other, then you can be confident that the number you got is pretty accurate and very close to your real refresh rate.

It's important to use a browser that works (Chrome and Firefox should be OK), and that if you're using Windows 7, Aero must be enabled (the test needs Aero's vsync in order to detect your refresh rate.) You also need to make sure that GPU acceleration is enabled in your browser, otherwise you'll get wrong results.

You only need the first three decimals of the detected number. If the result is something like "59.940875" for example, you can consider "59.940" as the important part for simplicity.

Step 2: Use RTSS's new fractional frame cap feature

Unless you're using a very old RTSS version (so please make sure you have a recent version) you can set a denominator for the frame cap. For a 59.940Hz monitor, you'd cap to 59.930FPS (59.940 - 0.01 = 59.930). For a 119.982Hz monitor, you'd cap to 119.972FPS (119.982 - 0.01 = 119.972).

Do do this, you need to edit the profile file of RTSS (to set this globally, you need to edit the "Global" file inside the "Profiles" folder of your RTSS installation directory.) There's no GUI for this. For a 119.972FPS cap, you would need this in the profile file:
Code:
[Framerate]
Limit=119972
LimitDenominator=1000

For a 59.930FPS cap, you'd use:
Code:
[Framerate]
Limit=59930
LimitDenominator=1000

Step 2 different method: Using CRU

Instead of using a fractional RTSS frame rate limit, you can instead continue using the default frame cap, but instead modify your monitor's refresh rate slightly. You can do that using CRU:

https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU

For example, if you want to cap to 60FPS, modify your 60Hz mode to 60.01Hz. For 120FPS, modify your refresh rate to 120.01Hz. Please note that it's usually not possible to get exactly that number! Again: 0.01 is just a ballpark number. If 60.01Hz or 120.01Hz are rounded off by CRU to 60.008 or 60.012 for example, or 120.009 or 120.013 in the 120Hz case, that's fine! Just use a number between 0.007 and 0.015 and it will be fine.

The downside to using CRU for this is that you need to re-apply your edits every time you upgrade your GPU drivers. Fortunately that's easy since CRU has an "export" button where you can save your custom resolutions to a file and then use "import" after driver updates.

After you've edited and activated your tweaked refresh rate, you should now go to the refresh rate testing sites mentioned previously and verify that your new refresh rate actually works.

If all went well, you can now just cap normally with RTSS. For 60.01Hz cap to 60FPS, for 120.01Hz cap to 120FPS. Obviously you can do this for any refresh rate you want. Cap to 75FPS if you've added a 75.01Hz mode, 90FPS for 90.01Hz, etc. The only important part is that "0.01" difference.

Result

This will keep the pre-render and other frame buffers empty by stopping the game from rendering frames faster than your refresh rate. And empty frame buffers means no added latency due to buffering.

If you don't do the above, then setting pre-rendered frames higher than 1 will result in more input lag, and can result in bad frame pacing in some games.

And even if you do the above, setting this value to 1 still helps as a guard against temporary framerate fluctuations (no frame capper is perfect), giving a more consistent input lag value.

Keep in mind that all this requires a PC that's able to render frames fast enough. Since the above keeps render/frame buffers empty, it means there's no guard against frame rendering time spikes. If your PC can't maintain a solid 60FPS (or whatever your refresh is), then you might be better off not doing any of this.

If your PC is fast enough though, then this is an excellent way of minimizing vsync input lag and maximizing smoothness by having good frame pacing (meaning frame times that match your refresh rate.)
 
I would be very interested in what happens when you set the "pre-rendered frames" to 1 so the latency is only 1 frame even without the limiter and then limit to a full half fps below the refresh rate so there will be stutter once a second but for me the input lag is completely gone then (well the same like without vsync).

I'm and AMD user so I don't think I've got that option. Google says "We don't see a per-application setting for the flip queue size in Radeon Settings, so we're guessing that Crimson manages it automatically."
 
Upvote 0
@RasmusP ,

I still can't save the Global file..
Did you check if it's set to read only in its properties?
I didn't think of it as it wouldn't make sense why it should be set to read only but since I can edit and save the file even while rtss is running (the settings won't apply though!), I think you should check for that...
 
Upvote 0
I'm and AMD user so I don't think I've got that option. Google says "We don't see a per-application setting for the flip queue size in Radeon Settings, so we're guessing that Crimson manages it automatically."
Yeah that makes sense. Read similar things... Nvidia's default is "let the application handle it". While 3 is the standard from what I read and how the input lag feels like (default or 3), setting it to 1 gives heavy micro stuttering for some games on some cards (rocket League with a gtx 670 for example). 2 is a little input lag reduction while not inducing any stuttering.

Could you check though if the Latency changes when you go down half an fps to 59.50 fps? From my experience the hiccup will be definitely visible but the input lag will be gone completely (used that for battlefield 4 as the game is so fast paced that the hiccup isn't noticeable while playing).
 
Upvote 0
@RasmusP @Martin Vindis ,

I can save it now. What settings to use in Rivatuner after I edited the Global file?
The settings that are completely and in-depth explained in his first post :p
Open the vsync tester page, put the determinator to 100 (enough in my opinion) and decrease the fps from your monitor's refresh rate until the input lag is gone (or gone enough). The limiter works on the fly so go on track and then lower it and drive again. To check if the limiter etc is working correctly put in a value like 600 instead of 6000 and it should stutter like hell since it will limit to 6 fps :)
 
Upvote 0
Yeah that makes sense. Read similar things... Nvidia's default is "let the application handle it". While 3 is the standard from what I read and how the input lag feels like (default or 3), setting it to 1 gives heavy micro stuttering for some games on some cards (rocket League with a gtx 670 for example). 2 is a little input lag reduction while not inducing any stuttering.

Could you check though if the Latency changes when you go down half an fps to 59.50 fps? From my experience the hiccup will be definitely visible but the input lag will be gone completely (used that for battlefield 4 as the game is so fast paced that the hiccup isn't noticeable while playing).

I found something called RadeonMod which lets you set the flip queue size but I got the exact same results. Makes me think that flip queue size is set behind the scene in game by ISI/S397 which would make sense for any sim racing title as input lag is a big no no.

I also tried to set the limiter to -0.5 with the same result. Hiccups were more noticeable though so I'm sticking with -0.01 as I don't notice them at all with that value.
 
Upvote 0
  • Deleted member 197115

Still curios if actual gain, if any, accompanied by random hiccups worth it over butter smooth prerendered frames set at 1.
Did anyone bother measure the difference?
Is it even perceivable?
 
Upvote 0
Still curios if actual gain, if any, accompanied by random hiccups worth it over butter smooth prerendered frames set at 1.
Did anyone bother measure the difference?
Is it even perceivable?
No need to test it. When I played battlefield 4 I used vsync with pre-rendered frames at 1 for quite a long time. Then I read about this trick and the Bf4 console allows for decimal fps limits. The input lag was just gone!
With a mouse it's really noticeable... I thought for a long time that Bf4 would just be a bit spongy but I was good enough with it so I didn't bother.
Day and night with the limiter tric! Shame I never really played it again though...

Couldn't use the trick in other games yet as they only allow a limit for full fps and with 59 the trick works bit the hiccup is brutal!
Now with the determinator it works with everything, just awesome!
 
Upvote 0
This sounds great, thank you. I hate both tearing and vsync lag, usually opting for minimal tearing with vsync off and framerate limit at my monitor's refresh rate (best what I could come up with after fairly extensive testing), so I'll definitely be checking this out ASAP.
 
Upvote 0
Well, after testing AMS and R3E...not sure if it's even doing something for me. AMS keeps running with Vsync off for some reason, no matter how I set it up, so no difference there, and as for R3E, I honestly can't see (emphasis on "see", didn't do any real measurements) a difference between the lag with this and just running vsync normally. Tried tweaking the limiter number, no real difference as well. But the RTSS part is definitely working, since if I turn the vsync off in R3E, I can finetune the tear position by tweaking the limit number. I had no idea you can set the limiter to fractions in RTSS, so at least this is certainly worth it.

I wonder if it has something to do with the fact that I'm running Win 10 with latest updates, since there were some quite significant changes in regard to fullscreen rendering in one of the big previous updates...

I still can't save the Global file..

Just to be sure - you are editing the file as Administrator, right? Because given the location of the file, regular user won't be able to edit it, lacking the write permissions to it.
 
Upvote 0
I was having issues with AMS not running with Vsync as well. Not sure what I did to get it working again. There are a few issues with AMS since the last update so I'm expecting a hotfix soon and knowing Reiza it'll probably be here sooner then expected.

I've tried this with AMS, RF2 and AC and it's making a big difference for me. Done measurements in RF2 and AMS to confirm this.
Can't see why it wouldn't work with R3E, could you maybe do some measurement and tell us the results?
 
Upvote 0
OK, so I really should've been working, but it was bugging me too much and I had to try a few more things...

So yeah, managed to get AMS working with Vsync, and yes, the fractional framerate cap is definitely an improvement in input lag over regular vsync. Again no real measurements, but just by wiggling the wheel quickly, I can clearly see that. There's still some lag, it's not as lag-free as with vsync off, but it's noticeably less than just with unrestricted Vsync. I have to think on whether the little bit of residual lag is something I can live with.

Will see about R3E when I have some more time to spare, likely yesterday (or rather this evening, as it is known in the non-nocturnal part of the population ;) )
 
Upvote 0
(Yeah, it visibly works in R3E as well for me now, I did the tonight's race using this. There is some lag still, but it's very close to running without vsync.)
 
Upvote 0
Back
Top