Overview


DT is system expression that stands for delta-time. It represents the change in time in seconds since the last game tick.

Is DT consistent?


The underlying Construct 2 engine uses something called "requestAnimationFrame" (underlying v-sync related browser timing) to attempt to peg the game tick at approximately 60 times per second; however, it usually matches the display refresh rate of the computer which is nearly always 60hz except in the case of some new 120hz monitors. This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate.

Note: Laptops can set alternate refresh rates which can have a direct impact on the FPS of a Construct project.

One should never have an event which runs as a factor of dt (eg: Every dt*X seconds conditional).
On a 120hz display, dt will average ~= 0.008, since the engine will attempt to run the game tick 120 times per second. So then, setting up an event which runs every 60*dt is going to run approximately once a second on a 60hz vsync, and once every 0.5 seconds on a 120hz vsync. Obviously not good, since the game behavior will be inconsistent depending on the hardware.

For setting up events that should run at specific times or intervals, either use the system expression "time" or events such as "Every X seconds". In this case, this event should just be "Every 1 second". For example, if you wanted to schedule a one-time event to run 5 seconds in the future, you could record a instance variable: NextActionTime = time + 5. Then in the event:

If time >= NextActionTime & Trigger Once ---> Do something here.

You should use dt as a means of scaling movement/velocity/vectors/etc. So for example, let's say you have some Sprite1 with CustomMovement, and you want it to move approximately 100 pixels every second. Under an event:

Every Tick (aka every game cycle): Move Sprite1 by dt*100.

This way even if dt fluctuates because of slowdown or because of computers with different refresh rates, you are guaranteed a constant rate of movement. However, if the framerate drops significantly, DT will rise in proportion. This can result in erratic looking movement, and also cause sprites to move through each other.


Active Concerns


Since a game tick has to internally wait until the browser serves up a frame via v-sync, dt can on occasion drop significantly. For example, let's assume that the player's logic took 0.018 seconds (or 55 fps). At the same time, the monitor has *just* started its refresh. Construct is ready to run another game tick but as a result of requestAnimationFrame has to wait for the entirety of the refresh to conclude, presumably an extra 0.0167 seconds approximately on a 60hz monitor.

Could performance gains be had by decoupling the logic and render loops?
Logic would be run using javascript setTimeout( gameStep, 1 ), and render would continue to make use of requestAnimationFrame.