The loop
A game is one loop that never stops: read the player's input, update the world, draw a picture. One trip round the loop makes one frame, a single still picture. Shown fast enough, frames look like smooth motion.
Step one: read input. The game checks what the player did since the last frame: keys pressed, the mouse moved, a button tapped. It only notes them down here; nothing on the screen changes yet.
Step two: update the world. Using the input and the time that has passed, the game moves every object a little, runs its physics and checks for collisions. The world is only numbers in memory, such as the ball's position x.
Step three: draw. The game turns the world's numbers into a picture, object by object, inside a hidden image called the back buffer. Drawing takes time, so for a moment that picture is only half done.
The screen shows a second, finished image: the front buffer. When the back buffer is complete, the two swap in one go, called a flip. The player never sees a half-drawn frame, so the picture does not flicker.
The frame budget
Many screens refresh 60 times a second (some run faster), so many games aim for 60 frames per second. That leaves 1000 ÷ 60 ≈ 16.7 milliseconds (ms) for each trip round the loop: input, update and drawing must all fit.
If a frame takes longer, say 21 ms, it misses the screen's next refresh. With vsync (waiting for the refresh) the old picture stays up for two refreshes, 33.3 ms. The player sees a stutter: a dropped frame.
Time and motion
Frames do not all take the same time, and slower computers make fewer of them. If the ball moves a fixed 4 pixels every frame, at 60 frames per second it goes 240 pixels in one second, but at 30 only 120.
The fix is delta time (dt): how long the last frame took, in seconds. Move by speed × dt instead. At 240 pixels per second, a 60 fps frame moves 4 pixels and a 30 fps frame 8. Both balls arrive together.
A variable time step updates once per frame with that frame's dt. Physics often prefers a fixed step: always update by exactly 1/60 s, as many times as the time owed. After a slow 33.3 ms frame, update runs twice.
Each update also checks collisions: has the ball reached the wall? If so, put it back at the wall and reverse its speed. Big steps make this harder: a fast object can jump right past a thin wall (tunnelling).
What happens
;; step 1/11 · loop game loop repeat forever: 1 read input what did the player do? 2 update move the world on a little 3 draw make one picture (a frame) one trip round = one frame about 60 trips a second look like smooth motion
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). 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.