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;


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

    render(lag / MS_PER_UPDATE);

  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – DMGregory
    Jan 22 '17 at 1:44
  • \$\begingroup\$ 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. \$\endgroup\$
    – Ali1S232
    Jan 22 '17 at 10:21
  • \$\begingroup\$ @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). \$\endgroup\$ Jan 22 '17 at 18:35
  • \$\begingroup\$ Don't do running == true. Just type running \$\endgroup\$
    – LukeG
    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.

For example instead of

x+=3;//Move 3 spaces every step

x+=3*dt;//move 3*dt every step.

dt is the time since the last frame. If the game is running slow, dt will be bigger, and things will move further to compensate.

Edit: milliseconds are typically abbreviated as ms rather than Ms

  • \$\begingroup\$ i added my current code so you can see what's going on. i only have the loop as of now, which is why i'm worried it'll get more inconsitent when i start actually adding code in update(). i do know it's not Ms, but my phone changed it automatically for some reason. \$\endgroup\$ Jan 22 '17 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.