Addendums

I’m thrilled at the reception this blog post originally received, and I want to make sure this is the most up to date and thorough resource for this common gamedev problem out there. So I will update this article as new information is brought to my attention, and I’m also adding a few more pieces of information here that I couldn’t find the place for in the original article.

Hybrid Approaches

Unity (and other big engines) use a hybrid approach. Unity provides Update() and FixedUpdate() callbacks separately. Update uses variable time steps and FixedUpdate uses fixed time steps, plus it automatically interpolates stuff like physics states and animation states. If you mix and match both of those update callbacks without knowing how they work under the hood, you end up getting weird stuttering inconsistencies in your unity project. It’s a common problem I’ve seen in unity games, so even if you are using an engine, you still should understand how this all works.

1000hz Fixed Update

I’ve seen a few people mention to me their solution to this is to just update at a fixed rate of 1000 times per second. Because the difference between doing 1 and 2 updates per frame is a lot more noticeable than the difference between 16 and 17 updates a frame. You can do this if your game is pretty simple, but it does not scale well to more complicated projects.

Timing Anomalies

You do need to account for various timing anomalies when measuring frame code. If delta time is less than 0, that means that the system timer wrapped around. If it’s really high, you probably don’t want to fast forward your game a ton in one step, so you probably should cap it. If you just clamp deltaTime to between 0 and <maximum delta time> (this is 8/60 (7.5fps) for me), that should account for most anomalies.

Resyncing

In my engine I have a manual callback I can use to “resync” my timer code (set the accumulator to 0 and delta time to 1/60 the next time through the loop), which I do after loading a level or swapping scenes. You need this because you typically don’t want the game to start each level by immediately trying to make up the time it spent loading.

Spiral of Doom

If your game cannot *update* at 60hz, you end up in a spiral of doom where your game can never catch up to where it should be, and so it will do more and more updates every time until it eventually just freezes. Cap your accumulator to a maximum (I use 8/60 (7.5fps) as the max) and it should prevent that issue. This will not be a fun experience for whoever is trying to play the game, but at least it won’t freeze.

Floating Point Inaccuracies

In this article and my monitor simulator code, I was using doubles for clarity. Using doubles or floats introduces floating point error, like adding 1.0/60.0 60 times in a row will not actually end up being exactly 1. In my engine I actually use 64 bit integers for my timer code instead to sidestep this. SDL reports the system timer as a 64 bit int, so I just keep it in this format to avoid the loss you get from converting it to a double. In the game itself, this gets converted to double, but the timer code keeps it as an int.

Situations where interpolation is not an option

Interpolation is the industry standard method of doing this, because it’s a good robust solution that works great in the majority of use cases. But this has resulted in a few people acting as if there is no reason to even consider lockstep, and existing resources about this basically never even discuss it. Ignoring the extra difficulty involved in getting interpolation working, there are a few situations where interpolation just inherently isn’t an option, like emulators. It’s up to you to determine what your needs and options are here for your specific use case.

Averaging Delta Time

Some games and engines average together the previous few time deltas to smooth out any single frame spikes. For example, instead of a single slow frame resulting in 4 updates on the next frame, it would do 2 updates for the next 3 frames instead. You do this averaging when you compute delta time, before adding to the accumulator.

Update Multiplicity

An uneven framerate is worse than a slow framerate. For this reason I have a setting in my engine called “update multiplicity” that basically just makes the game always do a multiple of N updates at a time.

while(accumulator >= (1.0 / 60.0) * update_multiplicity){

for(int i = 0; i<update_multiplicity; i++){

simulate_update();

accumulator -= 1.0 / 60.0;

}

}

Setting update multiplicity to 2 basically says “Act as if this game is running at 30fps even if it isn’t”. For people with low powered machines this is preferable to alternating between 30 and 60 rapidly. There’s probably some way to detect uneven framerates and just fall back to this, but I just have it as a manual setting for now.

Sample Code

This is production code from my engine that I have commented. It uses many of the techniques and tricks I’ve illustrated in this post. You probably can’t just plug and play this into your engine, but I’ve decided to put this up for reference because sometimes you just wanna see what everything looks like together.