Frame Rate

Summary

Frame rate is how many times per second the game loop completes a full cycle — process input, update, render — expressed in frames per second (FPS). A higher frame rate means the player sees more, smaller updates to the screen each second, which reads as smoother motion; a lower frame rate means fewer, larger jumps between what's shown, which reads as stutter. Frame rate is not fixed or guaranteed — it fluctuates based on how much work each frame does and how fast the hardware can do it.

Why This Matters

A game that assumes a constant, predictable frame rate breaks the moment that assumption is wrong — and it's always wrong somewhere, whether that's a lower-end device, a moment of heavy on-screen action, or simply a different monitor's refresh rate. A character whose movement code silently assumes "60 frames happen every second" moves twice as fast on a machine running at 120 FPS and half as fast at 30 FPS, unless the code explicitly accounts for how much time actually elapsed between frames (see [[CON-0034]]). Understanding frame rate — that it varies, and why — is the prerequisite for writing gameplay code that behaves consistently regardless of it.

Mental Model

Frame rate is how many flipbook pages you flip per second, not a fixed speed the story itself moves at. Flipping through a flipbook slowly still shows the same story, just in fewer, larger visual jumps between pages; flipping quickly shows the same story with more, smaller jumps, which looks smoother to the eye. The story — the actual state of the game world — should progress at the same real-world pace either way; only how finely that progress gets sliced into visible steps changes with frame rate.

Core Explanation

• FPS counts completed game loop iterations per second. 60 FPS means the loop's input → update → render cycle completed 60 times in the last second; this number is measured, not set — you don't declare a frame rate and get it, the engine reports whatever rate it actually achieved.
• Frame time and frame rate are inversely related. A frame budget of 16.67ms per frame corresponds to 60 FPS (1000ms / 60); a frame that takes 33.3ms to compute drops the achievable rate to roughly 30 FPS — more work per frame directly lowers the rate.
• Frame rate fluctuates based on scene complexity and hardware. A quiet menu screen might run far above the target rate; a scene with many enemies, particles, and physics objects can drop well below it — the rate is a live consequence of current workload, not a constant.
• Vertical sync (VSync) and refresh rate cap the displayed rate, independent of how fast the loop could otherwise run. A monitor with a 60Hz refresh rate can only show 60 distinct images per second regardless of how much faster the game loop computes them, unless the display supports a higher refresh rate.

Syntax / Theory

Engine-neutral (measuring frame time)

frameStartTime = now()
// ... process input, update, render ...
frameTime = now() - frameStartTime
currentFPS = 1.0 / frameTime

C# (Unity)

public class FpsCounter : MonoBehaviour
{
    void Update()
    {
        float currentFps = 1f / Time.unscaledDeltaTime;
        fpsText.text = $"{currentFps:F0} FPS";
    }
}

C++ (Unreal)

void AFpsDisplay::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);
    float CurrentFps = 1.0f / DeltaTime;
    UpdateFpsWidget(CurrentFps);
}

Both engines derive frame rate from the same measured per-frame elapsed time (Time.unscaledDeltaTime in Unity, DeltaTime in Unreal) rather than exposing frame rate as something you configure directly — you can only target it (with VSync or a frame-rate cap setting) or optimize toward it.

Practical Example

A performance overlay helps identify when a specific system is causing frame rate drops.

public class PerformanceOverlay : MonoBehaviour
{
    private float[] recentFrameTimes = new float[60];
    private int index;

    void Update()
    {
        recentFrameTimes[index] = Time.unscaledDeltaTime;
        index = (index + 1) % recentFrameTimes.Length;

        float averageFrameTime = recentFrameTimes.Average();
        averageFpsText.text = $"Avg: {(1f / averageFrameTime):F0} FPS";
    }
}

Averaging over recent frames (rather than showing a single frame's instantaneous rate) gives a more stable, readable number, since raw per-frame FPS can spike noisily even when overall performance is fine.

Common Mistakes

• Treating frame rate as something the game "has," rather than something that's measured and varies. Code or design decisions that assume "the game runs at 60 FPS" will misbehave the instant that's not true — which happens routinely on different hardware or under load.
• Confusing frame rate with refresh rate. A 240Hz monitor doesn't make a game run its logic faster — it only allows more frames to be displayed per second if the game loop can actually produce them that fast; the two are related but distinct.
• Chasing an unrealistically high frame rate at the cost of visual quality or development time, when the actual goal (smooth, responsive gameplay) is often achievable at a lower, stable target rate — a stable 30 FPS often feels better than a rate that swings wildly between 20 and 90.
• Optimizing frame rate without first measuring what's actually slow. Guessing at performance fixes without profiling wastes effort on systems that weren't the actual bottleneck.

Game Development Example

A mobile game deliberately targets a lower, stable frame rate to conserve battery and thermal headroom, rather than chasing the highest possible number.

void Start()
{
    Application.targetFrameRate = 30; // Caps the loop's rate intentionally.
    QualitySettings.vSyncCount = 0;   // VSync would otherwise override the cap.
}

This is a deliberate design trade-off: a consistent 30 FPS is often more pleasant to play, and much less taxing on a phone's battery, than an uncapped rate that swings unpredictably between 45 and 90 depending on scene load.

Best Practices

• Measure actual frame rate (and, more usefully, frame time) before making performance changes — never optimize blind.
• Write gameplay logic against elapsed time (see [[CON-0034]]), never against an assumed fixed frame rate.
• Consider capping frame rate deliberately for consistency (especially on mobile or when frame pacing matters more than raw peak performance).
• Treat a stable, lower frame rate as often preferable to a higher but unstable one — sudden drops are usually more noticeable to players than a consistently moderate rate.

Exercises

1. Build a simple on-screen FPS counter (see Syntax / Theory) and observe how it changes between an empty scene and one with many moving objects.
2. Take the PerformanceOverlay example and reduce the sample window from 60 frames to 5 — describe how the displayed number's stability changes and why.
3. You're building a game for both high-end PCs and low-end mobile devices. Decide whether to target one uniform frame rate across platforms or a different target per platform, and justify the trade-off.
4. Research what "frame pacing" means (distinct from raw average frame rate) and explain why a game could report a high average FPS while still feeling stuttery to play.

Related Concepts

• Game Loop — frame rate is a direct measurement of how fast the game loop's iterations are completing; understanding the loop is necessary before frame rate has any meaning.
• Delta Time — the per-frame elapsed time value that varies inversely with frame rate, and the mechanism that lets gameplay code stay correct regardless of the current rate.
• Data Types — measuring and averaging frame times correctly depends on understanding floating-point precision and the units involved (seconds vs. milliseconds).

Further Reading

• KNOWLEDGE_SCHEMA.md — GDKB's concept maturity ladder and cross-linking rules, which this document follows.
• Unity documentation — Time and Frame Rate Management: https://docs.unity3d.com/Manual/TimeFrameManagement.html
• Unreal Engine documentation — Frame Rate and Timing: https://dev.epicgames.com/documentation/en-us/unreal-engine/frame-rate-and-timing-in-unreal-engine