What Delta Time Algorithm does C2 use ?

Hi,

I was wondering what DT Algorithm C2 uses, is it anything like ?

last = new Date().getTime();

dt = 1000 / 60; // constant dt step of 1 frame every 60 seconds

function animationLoop() {

now = new Date().getTime();

passed = now - last;

last = now;

accumulator += passed;

while (accumulator >= dt) {

update(dt);

accumulator -= dt;

}

draw();

}

Which by great example is described here http://blog.sklambert.com/using-time-ba ... implement/

or something similar?

It does one update and draw per tick, with dt being the time since the last frame as measured by the high-resolution timer API where available (instead of Date.getTime() which does not have sub-millisecond precision). There is also no assumption that the display will be running at 60 FPS, since displays which run at different refresh rates exist.

The way I see it multiple updates per draw is just a good way to burn CPU time for little benefit. If there are fast moving objects you want to collision test more accurately or something like that, then a specific feature to handle that case is far more efficient than running the entire game's logic repeatedly.

Many thanks

I see your logic, less cpu overheads/interrupts, I can imagine that you have been through a lot of scenarios with Time based, Vertical synchronisation rates, e.t.c, very difficult when there are so many different refresh rates and browser development decisions that are beyond your influence.

Great product btw.

Cheers again

A good article to read for those who are interested.

http://www.html5rocks.com/en/tutorials/speed/rendering/

Just to add to the discussion -

"Old-style" performance timers have also become less and less accurate and reliable due to more recently designed CPUs scaling their internal clocks dynamically (downclocking or upclocking, on a per-core basis, up to the max frequency they are sold for). Therefore you have to query the system's frequency very regularly to try to keep in sync, and you're never guaranteed the clock speed you got a few ms ago is still valid and/or is a good approximate for the core that executes your instruction.

Low-level high resolution timers are definitely the most reliable solution. This is true for desktop computers, but also consoles and mobiles.

As for fast moving objects and collisions ; it's much easier to make a consistent physics implementation at a stable fps (which is why certain physics modules of game engines usually run at a different constant frequency, e.g. 15 or 30 fps), and use continuous collision detections with swept surfaces/volumes specifically for objects that require it.