TL;DR: A game can render many frames while moving objects in visible steps because simulation updates and display frames use different clocks. A fixed simulation interval makes behavior easier to reason about; interpolation provides positions between completed updates. The engineering task is to assign input, collision, cameras, animation, and discontinuities to the correct timeline. Interpolation does not repair an overloaded simulation or guarantee deterministic multiplayer behavior.
A fictional platform game called Copperline reports a steady 144 frames per second. Its character nevertheless shivers while riding an elevator. The art team suspects the sprite animation. The programmer doubles the physics frequency. The producer asks whether the minimum system requirements should rise. All three responses are premature because the team has measured how often pictures appear without recording which simulation state each picture contains.
This article treats Copperline as a timing laboratory. Its measurements are invented to make the arithmetic inspectable, and its design decisions are examples rather than engine defaults. The goal is to distinguish several bugs that look similar on a recording: uneven presentation of valid movement, inconsistent integration, a camera sampling another clock, missed input, and genuine inability to keep up. Those faults require different repairs.
The conceptual starting point comes from Godot's explanation of physics ticks and rendered frames. These are separate activities. The renderer may produce several images between two simulation updates, or one image after several updates. A movement system should therefore specify how a completed state becomes a visible position instead of assuming that every draw corresponds to exactly one new simulation step.
Experiment one: draw the positions you actually have
Imagine a crate moving horizontally at exactly six meters per second in a deliberately simplified simulation. The simulation updates fifty times per second, so every update represents twenty milliseconds. Its positions after successive steps are zero, twelve centimeters, twenty-four centimeters, and thirty-six centimeters. This arithmetic describes constant velocity; it makes no claim about the behavior of a particular collision solver.
Now render at one hundred frames per second. If the renderer always displays the latest completed position, it shows each simulation position twice. The sequence contains a stationary frame followed by a twelve-centimeter jump. Average speed is correct, and the frame counter looks excellent. The presentation is uneven because the available state advances less frequently than the display asks for a picture.
The case becomes harder to recognize when the frequencies are not simple multiples. At a hypothetical seventy-five display frames per second and fifty simulation updates, some positions persist for one display frame and others for two. The object appears to alternate its pace. Increasing graphics performance can change the pattern without fixing the relationship. A report saying that the problem disappears when the window is resized is therefore useful evidence about timing, not proof that the renderer alone is defective.
Copperline's first diagnostic overlay records four values for each displayed image: real elapsed time, latest completed simulation tick, the previous and current transforms, and the fraction used for presentation. The team also captures a stationary background reference. Without that reference, a moving camera can disguise world-space irregularity or manufacture apparent irregularity around otherwise steady objects.
The overlay is deliberately temporary. Players do not need a timing debugger in their settings menu. Developers need enough evidence to reproduce the failure and identify which clock owns each change. Once the fault is understood, a small performance trace can retain the useful measurements without exposing internal terminology in the product.
Experiment two: spend elapsed time in fixed portions
A fixed-step loop accumulates elapsed real time and consumes it in equal simulation intervals. In Copperline's example, a frame arriving after thirty-five milliseconds permits one twenty-millisecond step and leaves fifteen milliseconds in the accumulator. If the next frame arrives ten milliseconds later, the accumulated twenty-five milliseconds permit another step and leave five milliseconds.
This approach does not mean ignoring the clock. It means refusing to make the duration of a simulation update depend on whichever delay happened before the renderer returned. The game still advances according to elapsed time while expressing that advance through a sequence of intervals for which movement and collision behavior have been designed.
Consider an integrator that updates velocity from acceleration and then moves an object using that velocity. Two small steps can produce a different numerical trajectory from one large step. That difference matters near a platform edge, spring, or contact constraint. Multiplying all motion by an arbitrary frame duration solves only the simplest constant-speed example; it does not prove that every interaction remains equivalent.
Glenn Fiedler's original timestep discussion explains why unlimited variable intervals and expensive catch-up can both fail. For Copperline, the practical consequence is a written interval contract: ordinary gameplay advances through fixed twenty-millisecond updates, and unusual wall-clock interruptions are handled explicitly. The contract makes a bug reproducible because the investigation can identify the particular update at which the state diverged.
A fixed interval alone does not establish determinism. Floating-point behavior, iteration order, random-number state, parallel execution, and external inputs can still differ. A replay system needs to identify those dependencies separately. The benefit here is narrower and valuable: the duration of an update is controlled, so frame-rate variation does not silently change one major input to the simulation.
Experiment three: interpolate a picture, preserve the authoritative state
Suppose Copperline's two most recent completed positions are twelve and twenty-four centimeters. Five milliseconds remain in its twenty-millisecond accumulator. The presentation fraction is one quarter. Linear interpolation places the visible crate at fifteen centimeters: twelve plus one quarter of the twelve-centimeter difference. Collision logic still uses completed simulation states.
The renderer is drawing between known positions. It is not asking the physics solver to execute a partial step merely to supply a prettier picture. That separation allows a fast display to show several intermediate appearances while collision, triggers, and authoritative movement advance through the same full updates.
This ordinary interpolation arrangement presents a timeline behind the newest wall-clock instant. In the simplified accumulator model, the displayed state is approximately one simulation interval behind the target real-time simulation position. The tradeoff is smoothness from known information rather than a prediction about motion that has not yet been calculated. Describing interpolation as free responsiveness would hide that tradeoff.
Extrapolation takes another approach: project forward using velocity or another motion model. It can reduce apparent delay when the prediction is correct, but a collision or abrupt direction change can invalidate it. A predicted character may briefly cross a wall before correction. Choosing between these methods depends on the object and game; the mere existence of a velocity value does not make every future position safe to display.
Copperline uses interpolation for crates and platforms. Its local aiming reticle is a presentation element with its own responsiveness requirements, so it is not automatically attached to the crate policy. This is an ownership decision, not permission for multiple systems to overwrite the same transform. Each visible element needs one defined route from input or simulation state to screen position.
The elevator exposes a second clock
The elevator problem survives after crate interpolation is enabled. The reason is a parent transform: the character is updated during simulation, but the elevator's animated parent moves during rendering. The visible character inherits both changes. A developer examining only the character's script would miss the source of the inconsistent motion.
Godot's implementation guidance calls attention to indirect movement through animation, navigation, and parent nodes. Its documented guidance is engine specific, but the design question generalizes: which system writes each transform, and at what point in the update sequence? Copperline audits the full transform chain instead of only direct assignments to the player object.
The audit produces three separate responsibilities. Simulation owns the elevator's physical pose. Presentation derives a visible elevator pose from completed simulation states. The character's attachment or contact relationship is resolved under the game's movement rules, then presented using compatible timing. Mixing a current physical parent with an interpolated child can create relative movement that neither system intended.
The team creates a test scene with an untextured platform, one rigid box, and a stationary camera. It then adds the player, followed by the normal camera behavior. This order matters because the symptom can change when each layer enters. A complex production level may contain many plausible explanations; a stripped scene lets the team isolate the first dependency that introduces the failure.
The repair is accepted when the platform and rider maintain the expected relative movement across deliberately mismatched display rates. A single smooth recording at sixty frames per second is insufficient because matching frequencies can conceal the original defect. The test must exercise the relationship that previously failed.
Camera movement deserves a separate experiment
A camera can make every object appear to jitter even when each object's presentation is smooth. Suppose the world objects use interpolated transforms while the camera follows the latest completed physics position. Between simulation updates, the objects move through intermediate positions but the camera remains fixed; then the camera jumps. Relative screen motion becomes uneven.
Copperline compares three camera modes: a fixed camera, a camera following the same presented position as the character, and a camera with an intentionally designed smoothing filter. The fixed camera establishes whether world movement is sound. The matched camera checks clock consistency. The filtered camera tests the artistic response once the underlying timing is understood.
A smoothing filter introduces its own lag and can obscure a timing error. Making the filter stronger may reduce visible shaking while creating sluggish tracking. The correct question is whether the filter expresses the desired camera behavior, such as a gentle catch-up after a turn, rather than whether it hides a mismatch that should have been removed earlier.
Camera cuts also differ from continuous movement. When a cinematic switches viewpoints, interpolation across the old and new camera positions can produce an unintended flight through the level. The cut is a discontinuity and should reset the relevant presentation history. Designers can still author a deliberate camera transition, but that transition needs its own trajectory and timing.
For screen-space effects, the team checks whether motion vectors, attachments, and labels use the same presented coordinate system. A nameplate can vibrate above a perfectly smooth character if it samples a different pose. Visual coherence extends beyond the main mesh to every element whose position communicates a relationship to that mesh.
Input arrives between updates
A fixed-step simulation does not excuse missing a short button press. If input is sampled only as a current held state at the instant of each simulation update, a press and release occurring between updates may disappear. Copperline therefore distinguishes persistent state, such as a held direction, from discrete events, such as a jump request.
The input system records relevant events with enough ordering information to make their consumption explicit. A simulation update consumes a pending jump according to the game's rules. It does not consume the same edge repeatedly merely because several catch-up updates run before the next rendered frame. The details depend on the engine's input API, so the article's example describes a requirement rather than an invented universal function.
Jump buffering and coyote time are separate design features. Buffering can permit an input shortly before landing to trigger when the character becomes eligible. Coyote time can permit a jump briefly after leaving a platform. Both can improve the intended feel, but neither should accidentally emerge from render-rate-dependent polling. Their durations belong to the gameplay contract and should be tested independently.
A useful Copperline trace contains the physical input event, the update that consumed it, the resulting authoritative action, and the first displayed frame reflecting that action. Those timestamps separate device and operating-system delay from simulation scheduling and presentation. A player perceives the combined result, while the engineer needs to know which component can actually be changed.
The team avoids promising that doubling the update rate halves total input latency. It shortens one scheduling interval under suitable conditions, but display buffering, rendering, device polling, and frame delivery still contribute. If the higher update rate overloads the CPU, the final experience can become worse despite the smaller nominal interval.
Teleports, respawns, and newly created objects
Interpolation assumes continuity between its two endpoints. A respawn violates that assumption. If the previous transform is at the bottom of a pit and the current transform is at a checkpoint, blending between them shows a rapid trip through the intervening geometry. That visual trip is not a simulated path and should not be mistaken for one.
Copperline tags these changes as discontinuities. When the character respawns, its presentation history is reset to the new state. Godot documents a dedicated interpolation reset for this purpose; other engines expose different mechanisms. The important behavior is that old spatial history does not remain eligible for blending after the design has declared an instantaneous relocation.
Object pooling creates a related trap. A recycled projectile can retain presentation data from its previous life. On reuse, its first visible frame may interpolate from an unrelated location. A pool's activation contract should initialize both gameplay state and presentation history. Resetting only velocity and health is incomplete if stale transforms remain available to the renderer.
The same reasoning applies to large world-origin shifts. A coordinate-system adjustment must be coordinated across the states used for interpolation. Otherwise an object can appear to traverse the shift distance. This is a bookkeeping requirement introduced by the coordinate change, not evidence that interpolation is inherently incompatible with a large world.
Copperline adds targeted scenes for respawn, pooling, level transitions, and camera cuts. These scenes are short and observable. They catch a class of bugs that ordinary movement tests rarely encounter because ordinary movement satisfies the continuity assumption most of the time.
When the simulation cannot buy enough time
Now increase Copperline's crowd size until each twenty-millisecond simulation interval takes twenty-five milliseconds of CPU time to compute. The game is spending more real time than the interval it advances. Catch-up creates additional work, which creates further delay. Rendering intermediate positions cannot restore a simulation that continuously falls behind.
A frame budget therefore needs headroom. If ordinary simulation uses nearly the entire available interval, a brief spike can create a backlog that is difficult to clear. The team measures distributions and expensive scenes, rather than accepting an average that conceals occasional bursts. A market square with many interacting bodies may be more informative than a quiet corridor.
Possible responses include optimizing the costly work, reducing simulation complexity, changing the update frequency with a full design review, or limiting catch-up work under an explicit degradation policy. Each has consequences. Discarding elapsed time can make game time advance more slowly than wall time. Running an unbounded number of updates can freeze presentation. Neither behavior should be an undocumented accident.
Pause and background resume deserve their own policy. A single-player game returning after several minutes usually should not replay every missed physical interaction just to catch up with the wall clock. A networked game has different authority and synchronization requirements. Treating both situations as one enormous frame duration creates avoidable errors at the boundary between application lifecycle and gameplay time.
Copperline's performance report records both missed presentation deadlines and simulation backlog. The two measurements answer different questions. A GPU bottleneck can lower visible frame rate while the simulation remains timely. A CPU simulation bottleneck can corrupt the intended pacing even when simplified rendering looks cheap.
Rotation and collision reveal the limits of a straight line
The crate experiment used a position on one axis because its arithmetic is easy to inspect. A rotating object adds another choice. Interpolating numerical angle values without considering their representation can send a character the long way around when orientation crosses a wrap boundary. The visible result may be a dramatic spin even though the physical change was small. The renderer needs an interpolation method appropriate to its rotation representation and the intended path.
For a fictional compass marker moving from three hundred fifty degrees to ten degrees, the designer wants a short turn across zero. Averaging the displayed degree numbers directly produces one hundred eighty degrees, which points in the opposite direction. This simple example does not prescribe a complete three-dimensional rotation algorithm. It establishes why transform interpolation needs more thought than applying one arithmetic formula to every stored component.
Scale can introduce similar questions. If an animation deliberately flips a sprite by changing the sign of its horizontal scale, blending through zero may squash it before it reverses. That may be a desired effect, but it should not appear merely because a generic transform interpolation routine processed a discrete facing change. Copperline keeps the character's facing decision distinct from a continuous size animation.
Collision introduces a different limit. The interpolated picture between two valid positions need not describe the exact path the physics solver followed. An object that changes direction at a contact within an interval may appear to cut a corner when the renderer draws a straight segment between endpoints. Increasing the update rate, retaining a richer presentation path, or accepting a bounded visual approximation are different responses with different costs.
A cosmetic correction must not silently move the collision body. Otherwise the renderer becomes another writer of authoritative state, and the next simulation update begins from a position that the physics system did not choose. Copperline's debugging view draws both the physical shape and the visible sprite so developers can see when the two timelines differ. That view is a diagnostic aid; it is not a demand that every cosmetic effect align perfectly with collision geometry at every instant.
Finally, a successful smoothing change is checked against the game's readability. A fast projectile should communicate a plausible approach to its impact point. A moving platform should give players a useful indication of where they can land. If interpolation makes those cues misleading, a mathematically tidy implementation has still failed the design. The correct tolerance comes from the interaction being supported, then becomes a concrete scene that the team can replay.
A release test that measures the player's observation
The final laboratory run uses a constant-speed marker, an accelerating object, a collision, a riding character, a camera cut, a pooled projectile, and a short input pulse. Each exposes a different assumption. The team varies rendering cadence independently from the simulation rate and introduces a controlled stall so recovery behavior is observable.
The acceptance criteria describe results, not one preferred implementation. Constant movement should not inherit the repeated-position staircase in the tested presentation modes. Physical outcomes should remain within the game's intended tolerance across render rates. A discontinuity should appear as a discontinuity. A single input edge should produce at most the intended action. Recovery from a stall should match the declared time policy.
The report also records the limits of the experiment. Smooth presentation does not establish network fairness, deterministic replay, collision robustness at every speed, or an absence of driver-specific frame pacing problems. Those claims require additional evidence. Narrow claims make the successful test useful because another developer can tell exactly which uncertainty it resolved.
Copperline's original elevator bug ultimately required no new minimum hardware requirement. It required compatible timelines for the platform, rider, and camera, plus a reset when pooled objects reappeared. The frame counter stayed high throughout. The improvement was that each frame now represented a deliberate point on the game's presentation timeline.