Frame Rate and Delta Time

Definition: Frame rate is how many frames per second a game renders; delta time is the actual elapsed time between two frames, used to keep game speed consistent regardless of frame rate.

How It Works

Frame rate varies by hardware: a powerful PC might hit 144 FPS while a phone hits 30, and even one device’s frame rate fluctuates frame to frame under load
Delta time measures the real elapsed wall-clock time since the last frame, usually in seconds or milliseconds, read from a high-resolution timer
Every movement or physics calculation multiplies by delta time (position += speed * deltaTime) instead of adding a fixed amount per frame
This makes an object move the same real-world distance per second whether the game runs at 30 FPS or 144 FPS
Most engines compute delta time once per frame, at the top of the loop, and pass it down into every system that needs it that frame
A frame budget is the time allowed per frame to hit a target rate: 1000ms / 60 = 16.67ms per frame, 1000ms / 30 = 33.3ms per frame
VSync locks the frame rate to the monitor’s refresh rate to prevent screen tearing, at the cost of adding input latency and forcing the frame rate to a divisor of the refresh rate if a frame is missed
Frame time (milliseconds per frame) and frame rate (frames per second) are inverses of each other, but frame time is usually the more useful number for spotting inconsistent performance, since it scales linearly with actual cost

Under the Hood

The clamp step is easy to skip and is exactly where the classic “teleporting after alt-tab” bug comes from: without it, one huge delta time value gets multiplied into every position update for that single frame.

Worked example 1: frame budget math at 60 FPS

Given: a target of 60 FPS, and a single frame’s update + render work measured at 12ms
Step: frame budget = 1000ms / 60 = 16.67ms
Step: 12ms of work fits inside 16.67ms, so the game hits 60 FPS with 4.67ms of headroom (idle or vsync wait)
Answer: the frame completes on schedule; delta time for that frame is ~0.01667s, and a character with speed 5 units/sec moves 5 × 0.01667 ≈ 0.083 units that frame

Worked example 2: dropped frames and delta time compensation

Given: the same character (speed 5 units/sec), but frame 200 takes 50ms instead of 16.67ms due to a garbage collection pause
Step: without delta time, a fixed-per-frame movement of 0.083 units/frame would make the character appear to slow down during the stall, since real time kept passing but distance moved didn’t
Step: with delta time, movement for that frame = 5 × 0.050 = 0.25 units, three times the normal per-frame distance, covering the same real-world distance the 50ms of elapsed time called for
Answer: the character’s average speed over real time stays 5 units/sec regardless of the stall, at the cost of a visibly larger jump on the stalled frame, which is why clamping delta time to something like 0.25s exists, to cap how large that single jump can get

Worked example 3: clamping delta time

Given: an alt-tab pause makes the next measured delta time 4.2 seconds
Step: unclamped, position += speed * deltaTime would move a 5 units/sec object by 21 units in a single frame, likely through walls or past collision checks entirely
Step: with a clamp of dt = min(dt, 0.25), that frame instead uses 0.25s, moving the object 1.25 units, still large but survivable for collision and physics code
Answer: clamping trades perfect time accuracy for stability, the game “loses” the extra 3.95 seconds of simulated time rather than risk a broken physics step

Worked example 4: fixed-timestep accumulator

Given: physics must update at a fixed 60Hz (16.67ms per step) even though rendering runs at a variable 42ms per frame this frame
Step: an accumulator adds the frame’s real delta time each render frame: accumulator += frameTime (accumulator becomes 42ms)
Step: the loop runs while (accumulator >= 16.67ms) { physicsUpdate(16.67ms); accumulator -= 16.67ms }, executing 2 physics steps (33.34ms consumed) and leaving 8.66ms in the accumulator
Answer: physics always advances in identical, deterministic 16.67ms increments regardless of render frame rate, and the leftover accumulator (8.66ms) is used to interpolate the rendered position between the last two physics states so motion still looks smooth, a pattern popularized by Glenn Fiedler’s widely referenced “Fix Your Timestep” article

Why It Matters

Without delta time, a game runs at different effective speeds on different hardware, exactly the bug that made some early PC ports run correctly only at one specific frame rate
Frame rate stability (not just average FPS) affects perceived smoothness; a game averaging 60 FPS with frequent spikes to 20 feels worse than a steady 45 FPS
Correct delta time handling is what lets the same game logic run unmodified on a 30Hz mobile display and a 240Hz gaming monitor
Performance is usually judged by percentile frame times, not just the average; the “1% low” (the slowest 1% of frames) exposes stutter that an average FPS number hides completely

Frame Rate Targets by Platform

Platform / genre	Typical target	Why
Mobile, battery-sensitive	30 FPS	Halves GPU/CPU work and power draw versus 60 FPS
Console, current-gen	60 FPS	Standard baseline for responsive action games
Competitive PC / esports	144-240 FPS	Lower input latency, smoother tracking for fast aiming
VR	90 FPS minimum	Below this, the mismatch between head motion and rendered image causes motion sickness

History and Known Issues

Several shipped games have tied gameplay logic directly to a fixed frame rate instead of delta time, then broken when players uncapped it. Physics-heavy titles built on frame-rate-assumed timesteps are the most common victims: object interactions, ragdolls, or even game speed can behave incorrectly once the frame rate exceeds what the original timestep assumptions expected, which is why capping frame rate is a frequent recommendation in PC modding communities for older titles. Glenn Fiedler’s “Fix Your Timestep” article (2004) remains one of the most widely cited references for the fixed-update-plus-interpolation pattern used to avoid exactly this class of bug.

Input Latency and Frame Rate

Input latency is roughly the time from a physical button press to the resulting pixel change on screen, and frame rate is one of its biggest contributors
Given: at 60 FPS, a frame takes 16.67ms; an input sampled right after polling closes for that frame waits almost a full frame before it’s processed
Step: average added latency from frame timing alone is about half a frame period: 16.67ms / 2 ≈ 8.3ms at 60 FPS
Step: at 144 FPS, frame period drops to 6.94ms, so average added latency drops to about 3.5ms
Answer: doubling frame rate does not linearly double perceived responsiveness, but it does meaningfully cut input-to-photon latency, which is why competitive players chase high frame rates independent of visual smoothness

Common Pitfalls

Hardcoding movement speed without multiplying by delta time, tying gameplay speed directly to whatever frame rate the current hardware happens to hit
Not clamping delta time: a huge lag spike (alt-tabbing out, a loading hitch) can produce a massive delta time value that causes objects to teleport or tunnel through colliders on the next frame
Applying delta time to physics integration inconsistently, mixing fixed and variable timestep code in the same system, which produces subtly different results run to run
Assuming delta time is constant within a single frame when multiple systems read it, if one system mutates a shared “dt” variable mid-frame, later systems see the wrong value
Using delta time for network-synchronized logic without also accounting for clock drift between client and server, causing simulations to diverge over time
Reporting only average FPS in performance testing, which hides stutter that percentile frame-time metrics (1% low, 0.1% low) would catch immediately
Forgetting that uncapping frame rate on physics tied loosely to a fixed-rate assumption can change gameplay behavior, not just visual smoothness

Comparison

Approach	Update rate	Consistency	Typical use
Fixed timestep	Constant (e.g. always 1/60s per update)	Deterministic, reproducible	Physics, networked games
Variable timestep (delta time)	Matches actual elapsed time	Smooth on varying hardware, non-deterministic	Rendering, simple gameplay
Fixed update + variable render	Update at fixed rate, render interpolated	Best of both, more complex to implement	Most modern engines (Unity, Unreal)
No delta time (frame-locked)	One fixed amount per frame regardless of timing	Simple but breaks across hardware	Legacy/retro-style games only
Semi-fixed with frame skip	Fixed step, but skips or repeats steps to catch up	Deterministic, can visibly stutter under load	Older console titles with strict CPU budgets

Example

Unity exposes Time.deltaTime for variable-rate updates and a separate FixedUpdate() callback running at a fixed interval (default 0.02s, 50Hz) for physics. A character configured to move at 5 units per second moves exactly 5 units in one real second, whether the game renders at 30 FPS (each frame moving ~0.167 units) or 240 FPS (each frame moving ~0.021 units), because both cases multiply speed by that frame’s actual delta time. Godot exposes the equivalent value as the delta parameter passed into _process(delta) and _physics_process(delta), following the same fixed-plus-variable split.

FAQ

Is delta time the same thing as frame time? — practically yes in most engines, both represent the elapsed time used for that frame’s update
Why measure delta time from the previous frame instead of predicting the next one? — because the actual duration of the upcoming frame isn’t knowable in advance; using the last known interval is the simplest reliable estimate
Does delta time solve multiplayer desync by itself? — no, it keeps single-machine simulation consistent across frame rates, but networked games still need a fixed, server-authoritative tick rate to stay in sync between machines

Common Interview Questions

Why can’t you just add a fixed amount of movement per frame instead of using delta time? — because frame rate isn’t constant across hardware or even within one session, so a fixed per-frame amount ties gameplay speed to whatever rate the game happens to render at
What’s a typical delta time clamp value and why? — often around 0.1 to 0.25 seconds, chosen to absorb normal frame hitches while preventing a multi-second pause from producing a catastrophic single-frame jump
Why do some engines separate a fixed update from a variable render step? — physics needs deterministic, reproducible steps to stay stable and network-synchronized, while rendering benefits from matching the display’s actual refresh timing
What happens if delta time is measured with a low-resolution timer? — small per-frame movements round to zero or become jittery, since the timer can’t distinguish between similar short durations
Does higher frame rate always mean better gameplay? — not necessarily for logic correctness (delta time already normalizes that), but it does reduce input latency and makes motion look smoother to the eye

Measuring Frame Time in Practice

Most engines expose a built-in profiler overlay (Unity’s Stats window, Unreal’s stat fps/stat unit, Godot’s Monitor tab) showing per-frame time broken down by CPU and GPU work, letting a developer see exactly which phase (input, script logic, physics, rendering) is consuming the frame budget rather than guessing from the overall FPS number alone.

Referenced by

Dig deeper

Spot an error in this note?