Question Need help with weird jitter-like/unstable delta time ingame behavior.

Hello everyone,

I've encountered an issue with a game that's currently in early access on Steam, and I'm struggling to find a solution.

The issue is best illustrated by videos captured by different players. One video is recorded directly from the game (

) and another via a smartphone camera (https://youtube.com/shorts/WVHqzSFVvgM). During gameplay, I only change the timeScale to either 0 or 1 (essentially pausing and unpausing the game), so the issue seems unrelated to the code.

Upon further investigation, I discovered that this problem occurs only on high refresh rate monitors, and disabling G-Sync might temporarily resolve it. However, I'm eager to address the root cause of this behavior.

Key details:

Unity version: 2022.3.17f1
The game uses Cinemachine, and all camera-related movements are set to Fixed Update, consistent with Cinemachine's. Camera follows a Rigidbody that is moved within Fixed Update but has Interpolation enabled. Cinemachine Update Method is set to Late Update.

Time Settings: Fixed Timestep is set at 0.05 (errata: the video recorded with previous value set to 0.005), and Maximum Allowed Timestep at 0.1 (previously: 1s).

Overall, the game is well-optimized.

I would greatly appreciate any suggestions or insights!

 

Not just ANY game but Yet Another Zombie Survivors! My favorite survivors by far!


Observation: The first big jump at 0:04 is way too big for 0.1 timestep. I watched it in x0.25 speed. It's not possible for the player character to move this far in normal game time.

To me this seems as the usual catch-up when framerate is low - the game is making bigger jumps. But here the framerate may be dropping below the GSync minimum rate and I can imagine some (cheap or defective monitor? buggy drivers?) systems may simply stop rendering at very low framerates. That is why you don't see this catch-up frenzy where the whole seems to run on steroids for a split second - instead here it just jumps ahead because we don't see any render output where framerate is, say, below 30 Hz.

Which makes me wonder: is this catch-up frenzy happening at very low fps on non-Gsync monitors? I'm pretty sure this happened to me every once in a while. But with 0.1 max timestep it's probably limited to 2x speed than normal, which may be why I can't remember it too well.

The question would then be: how to detect this, and if my theory is true, how to prevent those gsync monitors from not rendering at all (or whether that's possible). I'd definitely be interested to get a log of the delta times (fixed and update) from affected players to confirm that these stay within limits. You may also want to double check any use of (fixed) deltaTime in case one was used where the other (fixed or non-fixed) should have been.


I could attempt to repro this for you. I have two 120 Hz capable displays. Wanted to play 0.6 for some time now but Fallout kept me busy.

I'll give it a good play in 120 Hz mode and with various settings to see if it pops up on my end. Might take a couple days but you'll hear from me if I can repro it.

 

Reflecting on what I said: I don't think this is a delta time issue within the code. It's FixedUpdate running multiple times for a single Update() in order to catch up. This is what advances the game simulation far ahead. At the same time there's nothing getting rendered, or just that one frame when the FixedUpdate catch-up is done.

Begs the question: what may be causing the game to run so many FixedUpdate calls per single Update? Perhaps the non-fixed delta time simply jolts way up, let's say to 1s then you'd be running at least 10 FixedUpdate calls in a single Update. This may not even be related to Gsync but rather something like slow disk access or background process blocking the game thread.

What behaviour would the game exhibit under that circumstance, getting the thread blocked for a second? You may be able to artificially force this by adding a Task.Delay to an Update method.

 

I'm delighted to hear that you're enjoying the game! We're trying to do our best.

Looking into the details, I just reviewed the repository and the timestamps, and there seems to be a slight correction. The videos were recorded using a version with a Fixed Timestep set as low as 0.005 and a maximum time step of 1 second. This was before I sat down to really dive into understanding and sorting out the camera/camera target relationship. The values I shared in #1 are my current local settings. So looks like your assumptions are quite precise.

Interestingly enough, I shared these videos with another player who had reported a similar issue and was quite communicative. They confirmed experiencing exactly what was shown. I even created a new build for them with adjusted values, but unfortunately, they still encountered the issue. Interestingly, the problem disappeared when they disabled G-Sync.

One aspect that continues to puzzle me is the slow-motion effect (particularly noticeable at 0:12) just before the "catch-up frenzy." Initially, I thought it might be due to the recording software, but now I'm not so sure. We've even acquired a G-Sync-supported high-end monitor for our office, but we're unable to reproduce the issue, even under heavy CPU load; it simply freezes momentarily without the delta-like behavior seen in the video.

Also, thank you so much for such a detailed answer! I'll try to get delta times logs from the friendly affected player. In case you went all-in and managed to get a repro somehow feel free to hit me with DM - I'll send you a Steam beta branch password with updated Time Manager values.

 

I've set up a diagnostic build to track time-related issues, and I'll take a look at it once I've sorted things out with the player. I log every call of Update and FixedUpdate, including their values, so this should help answer most of our questions.

Regarding Cinemachine, a small correction, I've made an adjustment recently. I changed its Update Method to Late Update because the target's Rigidbody has its Interpolation set to Interpolate. However, I'm still using Rigidbody.MovePosition within FixedUpdate to move it.

I'm unsure though if the recorded video shows previous settings or the ones I've just posted.
_

Okay, here's a summary of the current situation:

1. Original Recording Setup:
   • The videos were recorded with fixedDeltaTime = 0.005s and Maximum Time Step = 1s.
   • The Cinemachine settings used were:
     a) The camera-targeted object didn't have a Rigidbody, and its position was updated during the regular Update cycle.
     b) Cinemachine's update mode was set to Late Update.
     
2. My current Local Setup:
   • fixedDeltaTime = 0.05s and Maximum Time Step = 0.1s.
   • Current Cinemachine settings:
     a) The camera-targeted object now has a Rigidbody with Interpolation enabled and is updated only during Fixed Update.
     b) Cinemachine's update mode is still set to Late Update (due to target interpolation).

Despite these changes, the issue persists. I'm currently in touch with a player who can consistently reproduce the problem. I've created a build with additional diagnostics for time frames, and I'll share the logs and possibly a new video recording once I receive them. I'll keep this thread updated with further information.

 

Okay, so it's me again. @CodeSmile @Tautvydas-Zilys - I've received both the log and a video from a friendly player of us.

A video:

A log: attachment (FPS field looks like isn't accurate, it was a third-party script but it looks like it should matter here anyway).

You can notice both some stutters here and the fact that the game slows down with time.

 

Oooh, okay, I'll try to upgrade Unity and see how it goes. It might've started to occur after an update where we upgraded from 2021.

Yup, see the attachment (FrameTimeDiagnostics.cs). The delta times of 0 reflect timeScale = 0, those are the "level-up" parts of the video where I indeed change the timescale to 0, just to pause the game.

One more thing, that we just noticed, inside the log. RealtimeSinceStartup between Update calls does not reflect deltaTime, realtime difference is about ~60ms each frame, while deltaTime is ~42ms, even though TimeScale equals 1.

I've just asked for that, will send it over after obtaining it but I don't remember anything wrong with reports from other players. One thing in common that players reporting the issue have is rather high-end PC and high FPS. They usually report it as "server lag" and "losing frames".



EDIT:
I've also added two attachments, a Diagnostics log and Player.log for this specific instance, unluckily though Player.txt is filled with warnings about font asset, but otherwise it should suffice, I personally can't find anything related to the issue there sadly.