r_ticstability makes game stutter

[Graf Zahl]

This is a problem I've been experiencing for quite some time now - frequently after an operation that pauses the game I experienced some stutter for the first few seconds after resuming.
I finally tracked this down to r_ticstability being set to true.

I'm not even sure what precisely happens here - all I notice is that the problem goes away when setting the CVAR to 0 .
I don't really know what to do with this so I just toss in the report here. For my personal use setting r_ticstability to 0 while using vsync on is enough, but I wouldn't be surprised if this is responsible for at least some reports that claim bad performance for the engine.

Does it even make sense to have this active for vsync on?

[dpJudas]

Those functions are trying to make it so that frames that don't tick take the same time to execute as those that do. The goal is to provide a consistent time difference between the frames presented to the player. This is a goal regardless of whether vsync is on or off.

Take the following situation: game tics take 20 ms and scene rendering takes 1 ms. In a vsync off situation this would produce the following frame presentation flow: 21 ms, 1 ms, 1 ms, 1 ms, 1 ms, 1 ms, 1 ms, 1 ms, 21 ms, 1 ms, 1 ms, etc. Very micro-stuttery.
With r_ticstability enabled the flow for vsync off instead becomes: 21 ms, 21 ms, 21 ms, 21 ms, ...

For vsync on it gets a bit more complicated. That's because the frame presentation times can now only really be at vsync intervals (16 ms, 32 ms, 48 ms, 64 ms, etc). Unfortunately none of those line up well with the 28 ms tick rate that Doom uses. The frames that don't tick take 1 ms to process and end up at the next 16 ms presentation interval. The frames that tick misses the presentation deadline, causing the previous frame to appear for twice as long: A A B C D E F F G H I J (if B is a ticking frame and G is a ticking frame, other letters non-ticking). In other words, the micro stutter is still there, just in a different form.

If we add ticstability on top, the non-ticking frames now also last 21 ms to process. That means it misses the presentation deadline every time: A A B B C C D D E E, etc. Stutter should be gone, but game now runs at 30 fps instead. How this affects the 28 ms tick rate I'm not entirely sure though - it is possible what you might be seeing is a situation where it then ends up ticking twice in the same frame, causing yet another type of stutter.

TL;DR: yes it makes sense to attempt it even with vsync on, but maybe we need a better overall algorithm than what it is doing right now?

[Graf Zahl]

I think what this needs is some threshold at which the compensation is capped. If for whatever unpredictable reason a single frame takes abnormally long it should be thrown away for consistency reasons. Would taking the average of the last 4 or so ticking frames be a better approach than taking the last value as an absolute?

[dpJudas]

Adding a cap would probably be a good idea, although I'm not sure this can really be the reason behind what you experienced. Reason being that it would have gotten a new value 28 ms later with the current code.

Smoothing the value might not be a bad idea as there is an inherent variation in tick time to begin with, which it now extends to last for all other frames in the same ticking bracket.