RTSS Framerate/Frametime Syncing -- Fluctuating Rendertime Problem

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
Post Reply
dandyjr
Posts: 1
Joined: 21 Jan 2023, 21:54

RTSS Framerate/Frametime Syncing -- Fluctuating Rendertime Problem

Post by dandyjr » 21 Jan 2023, 22:50

I've been defaulting to information here for a long time and have become a much happier gamer because of it. All of the issues/insecurities I've had in the past due to G-SYNC misunderstanding have come to an abrupt end thanks to the work that you guys and the rest of the community have done. Gaming has genuinely never been smoother and more enjoyable for me than it is now. I use a 144hz G-SYNC-compatible and most of my gaming tends to be single-player games and emulators other than League of Legends.

The concern I have today is that there are certain games and emulators that have fixed framerates (due to built-in VSync or other means) that have variable unstable frametimes that feel awful even with G-SYNC + VSync. I've always been told that using multiple framerate caps (capping a cap) is detrimental and shouldn't be done. My question is, does using RTSS to stabilize my frametimes pose any possible issues with the setup I'm using. The lack of knowledge is killing me!

User avatar
Chief Blur Buster
Site Admin
Posts: 10845
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS Framerate/Frametime Syncing -- Fluctuating Rendertime Problem

Post by Chief Blur Buster » 23 Jan 2023, 02:13

<Highlighting an Underrated Topic>

The use of two framerate caps actually helps these edge cases.

I've done it before for one game that had naughty frametimes. Won't always help, but metaphorically sometimes you need to use both a hammer and a screwdriver when the screw is stuck.

Using two concurrently fine-tuned frame rate caps can help these bad-tempered renderers, especially if you don't care about adding a very tiny amount of lag (but much less than VSYNC ON) to force smooth framepacing.

Another trick is uncapping the software (like letting an emulator run amok superspeed at infinite frame rates) and using RTSS instead, also helps framepacing massively since RTSS is microsecond-accurate. One example game that seemed to framepace better was Cloudpunk when using RTSS instead of the in-game cap or uncapped.

RTSS cap is smoother, while in-game is less laggy.

Now a super fine-tuned concurrent cap can produce a result that's roughly somewhere in between (smoother than in-game cap, while being less laggy than RTSS capping). But it's a very edge case, that is only needed with problematic situations like "fixed-framerate-ultravarying-frametime" situations.

VRR works best when gametime:photontime stays in sync, but gametime is often timestamped right before a very fluctuating rendertime, so massively fluctuating rendertimes can add stutter that punches through the stutter-smoothing effect of VRR. There are algorithms to compensate for this (e.g. rendertime-compensated gametime timestamps) but few engines do this, for latency reasons. So you sometimes have to BYOFRC (Bring Your Own Frame Rate Capper). Okay, useless new acronym invented :lol:

This is the type of topic that I wish programmers and software developers would talk more often, the role of fluctuating rendertimes self-adding stutter.

Frame pacing is a tough art to do without latency compromises.

So forum members, software developers, please talk more about this. This problem needs to be considered by game developers working on tomorrow's 1000fps 1000Hz ecosystem.

Gametime:photontime is gospel in ultra-accurate framepacing, but rendertimes will put an error margin in gametime:photontime sync. Basically gametime is the moment a frame's time is pre-calculated just before rendering, and photontime is when that frame's hitting human eyeballs. Rendering time will add variances between the two, which adds jitter/stutter, as a frame pacing problem that becomes more visible in the refresh rate race to retina refresh rates -- or even just trying to keep things stutter-free on a VRR display.

We shouldn't always need band-aids to fix this problem; e.g. that specific app would no longer need to RTSS to become a "frame pacing helper copilot-cap" by RTSS.

This is important for the refresh rate race.

</Highlighting an Underrated Topic>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
To support Blur Busters - see Multiple Lists of Best Gaming Monitors
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply