Construct makes use of delta-time in order to be frame-rate independent. A frame-rate independent game tries to ensure that a game behaves in the same way regardless of the actual FPS. In some older games, the movement of sprites in the game was proportional to the frame rate. This meant that if you tried to play the game on a modern system today, the high frame rate would cause everything in the game world to move extremely fast making the game virtually unplayable.

In most cases, this means that delta-time returns the actual time in seconds from the last game tick. However, if the frame-rate dips below 10 fps, Construct will cap the returned value of DT at 0.1 seconds. When this happens, the game will physically appear to slow down. As outlined in the article on delta time, Construct synchronizes the logic and rendering loop through something called requestAnimationFrame which is used internally by the browser to peg the FPS to the refresh rate of the local monitor, typically 60hz so 60fps.

Due to such factors as browser memory management and the diversity of platform deployment such as mobile devices, developers cannot expect an absolute constant value for dt and should therefore account for a range of DT from 0.01677 (on a 60hz monitor, 60fps) to as high as 0.1 seconds. Even resizing the browser or putting a different application's window in front of the active tab can cause it to dip by 5-10 frames.

Thus, even a well-optimized game that runs at an average of 60 fps may occasionally encounter fps spikes. If the spike in delta time occurs in a situation when fast-moving objects are on the screen, it may result in erratic looking movement, missed collisions, objects phasing through each other, etc. In a reflex based action game, this may result in the occasional player annoyance, while in a puzzle based game such an occurrence might actually break the game.

Example Scenario (Mario-type Platformer)

In a Mario game, people expect a relatively stable and consistent collision system. Players should be able to jump onto enemies such as Goombas and destroy them, whereas if they run into them from the side, Mario will be injured. Mario may encounter fast-moving objects such as a Koopa shell in his travels. As a pixellated retro game, a Mario platformer will probably have a relatively low resolution that is upscaled using point sampling.

The standard max fall speed of the Platform behavior is set to 1000 pixels per second. With a frame-rate that hovers between 50-60fps, this means anywhere from a 16 to 20 pixel Y-displacement on a single tick at an optimal framerate. It gets even worse if you're trying to determine if the collision was top-to-bottom, or a side-collision, etc. In a low-res pixel art game, a single character sprite might not be much bigger than 16x32.

Mario Jump Timing.png

In this example, the Mario sprite is using the built-in Platform behavior. Each afterimage represents a single game tick at which point Mario was rendered. At tick "Mario 1", the game's framerate accidentally dipped causing the next time Mario was drawn and processed by the game logic to be "Mario 3". As a result, the collision detection event sheet code may detect this as a "side collision" resulting in Mario getting injured. In fact, if the frame-rate hadn't dropped, the "On Collision" code would have been executed at "Mario 2" and the koopa would have been properly killed since Mario landed on top of it.


The physics behavior is a noted exception to most behaviors which rely on delta-time. Physics by default make use of a fixed-time step to ensure that a simulation is reliable and reproducible. For more information, see "Set stepping mode" in the physics entry of the Construct 2 manual.