# How much do inconsistencies in update timing matter?

Yesterday I wrote my first game loop with fixed timesteps. It is supposed to run every 50 ms, however it runs at 50-53 ms. Does it matter?

I'm guessing no, but I figured I would ask anyway.

startTime = std::chrono::high_resolution_clock::now();

while(running == true){

updateTime = std::chrono::high_resolution_clock::now();

deltaTime = std::chrono::duration_cast<std::chrono::milliseconds>(updateTime - lastUpdateTime).count();
lag += deltaTime;

eventChecker();
keyboardManager();

while(lag >= MS_PER_UPDATE){
update();
lastUpdateTime = updateTime;
//cout << lag << "|";
lag -= MS_PER_UPDATE;
}

render(lag / MS_PER_UPDATE);

}

• The goal of a fixed timestep isn't that it runs at precisely regular realtime intervals, but that it updates your game state in precisely regular steps of "game time". That way inconsistencies in real-world timing don't cause the behaviour of your game simulation to diverge. Once you have that, the remaining issues tend to be aesthetic - ensuring the game still looks smooth even if the fixed timestep isn't precisely aligned with the frame time - interpolation helps here. Jan 22 '17 at 1:44
• completely unrelated the render function is probably going to fail, unless it is going to expect the left over time, in terms of fraction of update time. other wise your code is just fine and you shouldn't be worried about anything. Jan 22 '17 at 10:21
• @Ali.S ok, i'll get back to work then, thanks! i'll look into render() issues later(i don't have any sprites on the screen ATM so i'll need to write a little test). Jan 22 '17 at 18:35
• Don't do running == true. Just type running Apr 7 '17 at 13:17

Small variation might not seem like much, but it really depends on what you are doing in your loop. To put in persepective, running at 50ms a step gives you 20 steps per second. Running at 53ms a step gives you a bit less than 19 steps per second, so about one lost frame. In the span of a full minute you will loose about 68 frames (or about 3 seconds of game time)

If you were making a game heavily based on timing, this could be noticeable for the player. In an idle game that is meant to be left open in the background, this could result in drift. Some things like physics can also end up giving odd behavior.

HOWEVER, there is a bigger concern. You might want to read this post about update timesteps Right now you are getting that small variation. What will it be like in a month when you add more code to your game loop. If AI runs an A* algorithm in one, frame or you perform some search in another, those frames will likely not return in the time you are expecting.

Or try running your game on a crummy computer, or one with tasks running in the background.

If timing is important, do NOT, make things depended on your frame rate. The much better solution is to keep track of the time between frames.