EXTREMELY Confused Over "Constant Game Speed Maximum FPS" Game Loop

Question

I recently read this article on Game Loops: http://www.koonsolo.com/news/dewitters-gameloop/

And the recommended last implementation is confusing me deeply. I don't understand how it works, and it looks like a complete mess.

I understand the principle: Update the game at a constant speed, with whatever is left render the game as many times as possible.

I take it you cannot use a:

• Get input for 25 ticks
• Render game for 975 ticks

Approach since you would be getting input for the first portion of the second and this would feel weird? Or is that what is going on in the article?

---

Essentially:

while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP)

How is that even valid?

Let's assume his values.

MAX_FRAMESKIP = 5

Let's assume next_game_tick, which was assigned moments after initialization, before the main game loop is say... 500.

Finally, as I am using SDL and OpenGL for my game, with OpenGL being used for rendering only, let's assume that GetTickCount() returns the time since SDL_Init was called, which it does.

SDL_GetTicks -- Get the number of milliseconds since the SDL library initialization.

Source: http://www.libsdl.org/docs/html/sdlgetticks.html

The author also assumes this:

DWORD next_game_tick = GetTickCount();
// GetTickCount() returns the current number of milliseconds
// that have elapsed since the system was started

If we expand the while statement we get:

while( ( 750 > 500 ) && ( 0 < 5 ) )

750 because time has passed since next_game_tick was assigned. loops is zero as you can see in the article.

So we have entered the while loop, let's do some logic and accept some input.

Yadayadayada.

At the end of the while loop, which I remind you is inside our main game loop is:

next_game_tick += SKIP_TICKS;
loops++;

Let's update what the next iteration of the while code looks like

while( ( 1000 > 540 ) && ( 1 < 5 ) )

1000 because time has elapsed getting input and doing stuff before we reached the next ineteration of the loop, where GetTickCount() is recalled.

540 because, in the code 1000 / 25 = 40, therefore, 500 + 40 = 540

1 because our loop has iterated once

5, you know why.

---

So, since this While loop is CLEARLY depedent on MAX_FRAMESKIP and not the intended TICKS_PER_SECOND = 25; how is the game supposed to even run correctly?

It was no surprise to me that when I implemented this into my code, correctly I might add as I simply renamed my functions to handle user input and draw the game to what the author of the article has in his example code, the game did nothing.

I placed an fprintf( stderr, "Test\n" ); inside the while loop which doesn't get printed until the game ends.

How is this game loop running 25 times a second, guaranteed, while rendering as fast as it can?

To me, unless I am missing something HUGE, it looks like... nothing.

And isn't this structure, of this while loop, supposedly running 25 times a second and then updating the game exactly what I mentioned beforehand at the start of the article?

If that is the case why couldn't we do something simple like:

while( loops < 25 )
{
    getInput();
    performLogic();

    loops++;
}

drawGame();

And count for interpolation some other way.

Forgive my extremely long question, but this article has done more harm than good to me. I am severely confused now - and have no idea how to implement a proper game loop because of all these arisen questions.

Answer 1

I think the author made a tiny error:

while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP)

should be

while( GetTickCount() < next_game_tick && loops < MAX_FRAMESKIP)

That is: as long as it is not yet time to draw our next frame and while we have not skipped as much frames as MAX_FRAMESKIP we should wait.

I also don't understand why he updates next_game_tick in the loop and I assume it is another error. Since at the start of a frame you can determine when the next frame should be (when using a fixed frame rate). The next game tick does not depend on how much time we have left over after updating and rendering.

The author also makes another common error

with whatever is left render the game as many times as possible.

This means rendering the same frame multiple times. The author is even aware of that:

The game will be updated at a steady 50 times per second, and rendering is done as fast as possible. Remark that when rendering is done more than 50 times per second, some subsequent frames will be the same, so actual visual frames will be displayed at a maximum of 50 frames per second.

This only causes the GPU to do unnecessary work and if rendering takes longer than expected it could cause you to start working on your next frame later than intended so it is better to yield to the OS and wait.

Answer 2

Maybe best if I simplify it a bit:

while( game_is_running ) {

    current = GetTickCount();
    while(current > next_game_tick) {
        update_game();

        next_game_tick += SKIP_TICKS;
    }
    display_game();
}

while loop inside mainloop is used to run simulation steps from where ever it was, to where it should be now. update_game() function should always assume that only SKIP_TICKS amount of time has passed since last call. This will keep game physics running at constant speed on slow and fast hardware.

Incrementing next_game_tick by amount of SKIP_TICKS moves it closer to current time. When this gets bigger than current time is, it breaks (current > next_game_tick) and mainloop continues to render current frame.

After rendering, next call to GetTickCount() would return new current time. If this time is higher than next_game_tick it means that we are already behind 1-N steps in simulation and we should catch up, running every step in simulation at same constant speed. In this case if it is lower, it would just render same frame again (unless there is interpolation).

Original code had limited the number of loops if we are left too far away (MAX_FRAMESKIP). This only makes it actually show something and not looking like being locked up if for example resuming from suspend or game being paused in debugger for long time (assuming GetTickCount() does not stop during that time) until it has catched up with time.

To get rid of useless same frame rendering if you are not using interpolation inside display_game(), you could wrap it inside if statement like:

while (game_is_running) {
    current = GetTickCount();
    if (current > next_game_tick) {
        while(current > next_game_tick) {
            update_game();

            next_game_tick += SKIP_TICKS;
        }
    display_game();
    }
    else {
    // could even sleep here
    }
}

This is also a good article about this: http://gafferongames.com/game-physics/fix-your-timestep/

Also, maybe reason why your fprintf outputs when your game ends might just be that it did not get flushed.

Sorry about my english.

Answer 3

His code looks entirely valid.

Consider the while loop of the last set:

// JS / pseudocode
var current_time = function () { return Date.now(); }, // in ms
    framerate = 1000/30, // 30fps
    next_frame = current_time(),

    max_updates_per_draw = 5,

    iterations;

while (game_running) {

    iterations = 0;

    while (current_time() > next_frame && iterations < max_updates_per_draw) {
        update_game(); // input, physics, audio, etc

        next_frame += framerate;
        iterations += 1;
    }

    draw();
}

I've got a system in place which says "while the game is running, check the current time - if it's greater than our running framerate tally, and we've skipped drawing fewer than 5 frames, then skip drawing and just update input and physics: else draw the scene and start the next update iteration"

When each update happens, you increment the "next_frame" time by your ideal framerate. Then you check your time again. If your current time is now less than when the next_frame should be updated, then you skip over the update and draw what you've got.

If your current_time is greater (imagine that the last draw process took a really long time, because there was some hiccup somewhere, or a bunch of garbage-collection in a managed language, or a managed-memory implementation in C++ or whatever), then draw gets skipped and the next_frame gets updated with another extra frame worth of time, until either the updates catch up to where we should be on the clock, or we've skipped drawing enough frames that we absolutely MUST draw one, so the player can see what they're doing.

If your machine is super-fast or your game is super-simple, then current_time might be less than next_frame frequently, which means that you are not updating during those points.

That's where the interpolation comes in. Likewise, you could have a separate bool, declared outside of the loops, to declare "dirty" space.

Inside of the update loop, you'd set dirty = true, signifying that you've actually performed an update.

Then, instead of just calling draw(), you'd say:

if (is_dirty) {
    draw(); 
    is_dirty = false;
}

Then you're missing out on any interpolation for smooth motion, but you're ensuring that you're only updating when you've got updates actually happening (rather than interpolations between states).

If you're brave, there's an article called "Fix Your Timestep!" by GafferOnGames.
It approaches the problem slightly differently, but I consider it a prettier solution which does mostly the same thing (depending on your language's features, and how much you care about your game's physics calculations).