Lesson S4 · Special topics

Game loops and frames

A game is one loop that repeats three jobs: read the player's input, update the world, and draw a picture, about 60 times a second. Watch a frame token ride round the loop, see why each trip has a 16.7 ms budget, what double buffering and a late frame look like, and why moving by speed × delta time keeps a game the same speed on fast and slow machines.

10 min11 steps7 questionsIntermediate

Fig S4 · Interactive

Loading figure…

or ← →

Check yourself

7 quick questions

Pick an answer to see why. Your score saves with your progress.

01In what order does a basic game loop do its three jobs each frame?

Each trip round the loop reads what the player did, moves the world on, then draws one picture (a frame). Then it starts again.

02A game aims for 60 frames per second. About how long can each frame take?

One second is 1000 ms, and 1000 ÷ 60 ≈ 16.7 ms. Input, update and drawing all have to fit in that time.

03With vsync on a 60 Hz screen, a frame takes 21 ms. What does the player see?

The frame misses the 16.7 ms refresh, so it waits for the next one. The old picture stays on screen for 33.3 ms, which looks like a small jerk.

04Why do games move objects by speed × dt instead of a fixed amount each frame?

dt is how long the last frame took. A slow machine has a bigger dt, so each step is bigger and the ball still covers 240 pixels in one second.

05What does double buffering prevent?

The game draws into a hidden back buffer, then swaps it with the front buffer in one go. The screen only ever shows finished frames.

06Physics runs on a fixed step of 1/60 s (about 16.7 ms). The last frame took 33.3 ms. How many times does update run this frame?

A fixed step runs update in equal slices until the time owed is used up. 33.3 ms ÷ 16.7 ms = 2, so update runs twice, each time with the same small step.

07Why can a fast ball pass straight through a thin wall when the time step is big?

The collision check only looks at where the ball is after each step. If one step jumps from in front of the wall to behind it, the check never sees the ball touching it.

Key terms

Glossary

Game loop: The loop at the heart of a game: read input, update the world, draw a frame, and repeat until the game ends.
Frame: One still picture made by one trip round the loop. Shown quickly one after another, frames look like motion.
Frames per second (fps): How many frames the game makes each second. 60 fps leaves about 16.7 ms per frame.
Delta time (dt): How long the last frame took. Moving by speed × dt keeps motion the same speed at any frame rate.
Fixed time step: Updating the world in exact, equal slices of time (such as 1/60 s), as many as the time owed, instead of once per frame.
Double buffering: Drawing the next frame into a hidden back buffer, then swapping it with the front buffer the screen shows.
Vsync: Waiting for the screen's next refresh before showing a new frame, so a frame is never swapped in halfway through.
Collision check: A test, run during update, for whether two things touch, such as a ball reaching a wall.

Fine print

Notes and sources

The phase times on the frame-time bar (input 1 ms, update 3 ms, draw 8 ms) are a made-up example to show the budget. Real games vary a lot, and drawing is often handed to the graphics chip (GPU).
The code uses pygame: clock.tick(60) returns the milliseconds since the last call and waits so the loop runs at most 60 times a second; flip() shows the finished frame. read_input, update and draw are the game's own functions.
Without vsync a new frame can replace the old one halfway through a screen refresh, which shows as a horizontal tear. With vsync a late frame waits a whole refresh instead, which shows as a stutter.
Many engines run physics on a fixed step and drawing once per frame; some also blend between the last two physics states so motion stays smooth (Fiedler, "Fix Your Timestep!").

Quiz Unlocks after the last step.