Stutter Stutter or Smooth as Butter

[jimortality]

Brands Hatch especially, even in practice screen stutter. I think it's not just me and maybe down to the unreal engine? I've tried all different things so if you're smooth as Butter, please post your settings and how you're eliminating it. Thank you.

Acer Predator X34p
I 7-6700k
Nvidia 1080ti
16gb Ram a lam.
And not forgetting my brand new Master Cooler 212 Evo

 

[DrRob]

@RasmusP Initially I played around a bit with sub-60Hz still had stutters. I'm coming from early Homecinema projectors, so I know the problems. ;-) To be honest, I didn't approach this as a scientific project and am by no means a specialist here. Just fiddled about (and stopped when I the result was satisfying).
Thought it was easy enough to achieve my goal.
But maybe I am less sensitive to micro-stutters than I am to DLP "rainbow-effect".

Just yesterday I tried with the ultra-low latency for the first time. Didn't see any difference no matter which setting I selected. So, left it at default.

 

[Neilski]

Do you use pre rendered frames at 1 or 2 or the default of 3? It's now called ultra low latency or something similar in the Nvidia panel...

Is there a way to tell what a game is using? My control panel has that set (at present) to "Use the 3D application setting".

 

[RasmusP]

Is there a way to tell what a game is using? My control panel has that set (at present) to "Use the 3D application setting".

Some games like ac (with cm or in the ini) have a slider for it. Most games however don't..
But afaik the default is 3 because it gives gpu and cpu a full buffer and "one extra".
That's my understanding anyway..

Friend of mine had massive stutters in rocket league with his gtx 670 when using "1".
Although it wasn't above 60% load...
"2" was fine, 3 still helped against micro stutters.

However I could never solve stuttering in any game over the years by using more than 3...

That's why 3 is the overall default, while I'm always using 2 or 1 if it's working.

Interestingly this stuttering at 1 wasn't CPU limited or dependent of the gpu load.
He upgraded to a 1070, raised resolution via dsr so the load was the same.
Didn't change any setting, same cpu. Using 1 = no stutter.
Maybe gpu memory speed?

Anyway 2 is a good setting

 

[Case_]

@DrRob I still don't understand the point of using both vsync and framerate limiter at the same value as your refresh. You can't have higher framerate than refresh if you use vsync, and you're not limiting lower, so there are no benefits to input lag.

But I certainly envy you if you can play ACC with vsync on and not notice the horrendous input lag.

 

[RasmusP]

@DrRob I still don't understand the point of using both vsync and framerate limiter at the same value as your refresh. You can't have higher framerate than refresh if you use vsync, and you're not limiting lower, so there are no benefits to input lag.

But I certainly envy you if you can play ACC with vsync on and not notice the horrendous input lag.

Did you test this and had a look at frametimes? I did and it seems that vsync without a limiter can have some.. hiccups? I don't know a better word...
I don't know how it can stutter but it seems like sometimes there's really a hiccup and one frame gets displayed twice although the fps aren't coming down.
Here are some graphics I found very nicely made when I tested around 2019 or 2018..

 

[Case_]

I see some issues with this "proof", but OK.

 

[RasmusP]

I see some issues with this "proof", but OK.

Did some quick recordings with fraps (exact frame to frame time) and threw it into excel. No smoothing, same Axis:
Not sure where the bigger spikes comes from... Guess the vsync inside the pendulum demo isn't perfect (put the fps sliders in there to 300).

Here's how it looks like with nvidia forced vsync and "no vsync" in the pendulum demo:

 

[DrRob]

@DrRob I still don't understand the point of using both vsync and framerate limiter at the same value as your refresh. You can't have higher framerate than refresh if you use vsync, and you're not limiting lower, so there are no benefits to input lag.

But I certainly envy you if you can play ACC with vsync on and not notice the horrendous input lag.

I cannot give you an answer, sorry. I didn't approach this in a scientific way. I just discovered that this "works" for me. If I deactivate vsync or the framelimiter I get stutters all over the place. Honestly speaking I set this sim up to race. The less time I spend fiddling with the hard- or software, the more time I can invest in racing. Which leaves me satified without knowing "why".
I just wanted to give my feedback what worked for me. maybe this is of some use to anybody.

 

[Case_]

BTW, independent on this discussion, I just stumbled upon this:

"I would like to point out that while overlay monitoring software such as Afterburner seem to measure frame time as the delta time between two consecutive frames being submitted to the GPU, the programs I utilized do it as the delta time between two consecutive frames being presented to the CPU. I believe this is the more appropiate way to do it and a better representation of frame pacing, since, assuming game time and render time are in sync, the data being processed by the CPU determines what will be displayed in a frame. This is also the reason why Afterburner shows perfectly stable frame times when using the RTSS framerate cap, and because the way RTSS operates is by blocking the CPU from delivering a new frame to the GPU until a specified time interval is reached."

Some observations on Scanline Sync - Blur Busters Forums

 

[Case_]

BTW I did play a bit with the recommendations in the post in the link above, specifically this part as it concerns borderless:

For graphically demanding games in which you want a smooth and tear-free image, avoiding the input lag and frame pacing issues that comes with traditional VSYNC, use Scanline Sync in combination with Enhanced Sync/Fast Sync/borderless and give it a generous margin (scanline index at the middle or even at the top of the display, the equivalent of 1.5 or 2 pre-rendered frames instead of 3.5).

But I've had very inconsistent results with this. While it did lower input lag compared to full vsync, it varies wildly in regard of microstutter. Some games I tested so far have no issues (AMS, AMS2) and the method works nicely, some have some issues while also not reducing input lag as much (DR2), and as far as ACC is concerned, anything outside of true fullscreen and vsync off (with negative scanline sync) gives me unbearable input lag *and* stutter.

 

[Neilski]

It's possible that a decent part of why input lag doesn't bother me (as much as it does some people) could be that I invariably use a dash or bonnet cam, rather than a cam which lets me see that the wheel isn't moving perfectly in sync with mine...
(A helmet-cam is realistic in some ways but since I have neither triples nor VR I just can't see enough to drive the car.)

 

[Case_]

That would almost certainly be the reason. (Outside of the fact that how sensitive people are to it also varies from person to person.) You are certainly way less bothered with these if you don't see the wheel (so turning it off in those games that offer that would also work).

But the delay between the real wheel and the in-game wheel is downright painful at times in ACC, it feels like half a second or so. And even if it might not affect things as much as it might feel to you, you just can't help feeling that your responses are inherently too sluggish just because of that, especially in a situation where you need to do some quick corrections.

 

[DrRob]

Stupid question, but with input lag you just mean the difference of the real wheel vs. virtual wheel on screen?
I noticed that, but I only switch to visible wheel to adjust driver position, then switch it off again.
Any other problems with input lag? Seems I've been very ignorant here...
I didn't notice that my real wheel input results in a delayed response for the virtual car while cornering for example.

 

[Case_]

Well, it's hard to reasonably measure it when the wheel is not visible, but as mentioned, yes, I certainly feel like the game generally responds more sluggish as the visual input lag goes up, at least when doing quick corrections (as mentioned). I don't have as much experience with ACC in this regard, but in DR2 (which can also have a notable input lag in certain configurations for me, almost as bad as ACC) I certainly do seem to do better if I reduce the supposed input lag as much as possible.

Not sure how to measure actual input lag without looking at the virtual wheel. If you have any suggestions, I'll gladly test it.

 

[DrRob]

Thanks for explaining @Martin Fiala . Seems like I've been ignoring this thing altogether until now. I don't know if input lag kind of affected me in any way in reaction time and precision until now and if I kind of adapted to the situation somehow.....is this a thing for everybody? Not a big help here, sorry.

Normally I just get put off by a non-smooth, kind of slide-show feeling, so I did everything to have the game visuals as smooth as possible with less hicchups I could dial in. Never thought I produce another artifact with that...

Maybe I should stop here. I know how this goes.... I notice things and in the end I would have liked to not discover, because now I cannot "unsee" or "unfeel".
(I know this from homecinema with lipsync, rainbow effect,....)

 

[Case_]

Yep, these things tend to be a bit of a rabbit hole (And even if I realize it probably makes very little difference to my already abysmal driving, I'm kinda obsessed with it at the same time because there's that little voice that always goes "sure it probably means very little...but what if it still helps, at least somewhat? Do you really need more handicap than you already have?" )

 

[DrRob]

Cheers @Martin Fiala , I can relate to that. I tell myself that I just try my bestand go on with it.
I was just watching the ACR stream on twitch and could not comprehend them doing 2:19s on Spa every lap.
After all I want to have a fun time, feel immersed (no stutter!) and hope I can improve here and there.
I think I let the input lag topic slide for now....
Have a lovely evening.

 

[gyrtenudre]

I think I let the input lag topic slide for now....

Sorry to bring it up again then might even be slightly off-topic. But since we opened this discussion on the "weird" effects of the 59.99fps limiters I just want to say this last thing because I wouldn't want it in my game (see below), even though I also don't really notice constant input lag having a serious impact in my driving (well I would of course like to minimize it as the game then feels more "live" and responsive).

@Neilski @RasmusP Some of the links posted in the last few posts, can't remember which, had a reference to this neat tool CapFrameX, and it measures (Edit: approximates) input lag. So, my theory on how the 59.99 cap works and how it should cause some periodicity on input lag seems to be correct:

vsync+59.99fps

RTSS scanline sync

Not bloating this thread any further with other settings since they cause either worse input lag or stuttering/tearing (all except adaptive refresh rates of course).

my interpretation of the version with the cap is that it's worse than the uncapped one - it has stutter and a variable input lag, vs. no stutter and a consistent input lag.

This!

 

[Case_]

Yeah, I've tried the CapFrameX tool myself and sadly it only predicts/approximates the input lag, not actually measures it. (Not that I would know how you could make an utility to actually measure it.) It told me my input lag in AMS was the same as in ACC, and it very clearly isn't the case, even under the best circumstances. So not of much use in that regard.

Still a nice tool, though.

 

[Case_]

BTW an interesting thing...I've been tinkering with ACC the past few days trying to find some optimized settings...and while I was at it, I tried the bonnet view, as mentioned here before.

It's actually quite interesting. I've gained about 10% of fps just by using that view alone. And the interesting thing is it's not GPU-based gain, but very clearly a CPU-based one. For some reason, running in bonnet camera is noticeably easier on the CPU than cockpit cam or even dashboard cam. It's not due to the instruments on the dashboard, since you can turn an overlay with the dashboard on even in the bonnet cam and it doesn't affect framerate at all. So I guess something about the cockpit?

But it's an interesting way to gain some fps basically "for free". And the bonnet cam can even be set in the way so it is very close to the dashboard cam, all the way back and to the left (though I wish the adjustment range was a bit wider still)...

I might be using it more often.