Awful stuttering when running with a FixedTimeStep

Windows
1

I’m getting some horrible jitter/stutter every half a second or so when running my game with “IsFixedTimeStep” set to true.

Turning it off make the animation butter smooth again and so does turning on VSync but this is not an option because my CPU usage goes from 1-2% to around 45-50%(sometimes more).

I’m not sure whats causing this but I know it didn’t happen with my old XNA projects. Any Ideas?

2

fixed time step is like Vsync in a sense that it will double the timeStep if the initial one couldn’t be met.

So let’s explain it like this: If you set IsFixedTimeStep to true, by default it will set your target FPS to 60 (which is the default refresh rate for basically all lcd displays). You can change the target FPS to anything you like, it could be 120 or 10, this doesn’t really matter here.

So if you have a target frame rate of 60, your game has a timeStep of 16.66666 ms per frame. It has 16.6 ms to calculate all the data, send it to the GPU (well technically the last batch of data if we double buffer, but doesn’t matter here) and render all your stuff on the GPU to the screen. 16 ms. That’s the target.

Now, what happens if your PC just can’t do everything you wanted in 16 ms? Say, you have some expensive calculations, or high resolution effects and your PC only finishes all the stuff in 17 ms.

Well you missed the target. What can we do about it?
If you didn’t use fixed time step, the GPU would just refresh the backbuffer (your final output to the monitor) at every frame it gets. So 13 ms, ok, 17 ms, ok, 10 ms, ok.

Which is the reason we get ScreenTearing, because let’s say your monitor is currently refreshing the screen for a frame, but then - oh! - it gets a new one already. Ok let’s have the rest of the screen fillled with the next image already.

So it would be nice to have a set target framerate of the refresh rate of the monitor. 60fps / 16.666 ms.

Now back to the topic, what happens if our target is 16 but we only manage to deliver at 17 ms. We can’t just update the monitor screen at a different timestep once, since that would again introduce screentearing.

SO (FINAL CONCLUSION)
We double the target timestep. Our target is 16, the PC only hit 17, ok let’s have a timestep of 32 instead. Half the framerate, but at least consistent, right?
We still have the same update cycle as before, which is ideal, but we only refresh every second frame.

What happens if shortly afterwards we hit our 16ms target again? Well we go back to 16 ms.

Ok ok ok … so your issue is that there are SOME Frames which take longer than your fixedTimeStep TargetTimeStep.
If you have good framerate for 90% of the time, but then at 10% of the time the frames take a bit longer than they are supposed to the framerate is set to half for a fraction of a second. Causing stuttering.

So your issue could be

  1. Some operations only happen every few frames, but are very computationally intensive
  2. You create a lot of garbage and the garbage collector causes a frame drop for the short moment when it clears all your garbage.

TLDR: isFixedTimeStep will always have the same framerate, unless some frames took longer than expected, then it halfs the framerate until it gets good frames again.

Hope i helped.

1 Like
3

Thank-you for your huge reply! I know all the stuff you described so that’s a positive, I have done some tests timing each method:

[IsFixedTimeStep = false]
Update Time = 0ms
Draw Time = 16ms

[IsFixedTimeStep = true]
Update Time = 0ms
Draw Time = Fluctuation between 1ms and 16ms

[VSync= true]
Update Time = 0ms
Draw Time = 16ms

So my conclusion is the problem is still in IsFixedTimeStep not my code, the CPU doesn’t even break a sweat running my update method.