Game Development Reference
In-Depth Information
}
function tick() {
requestAnimationFrame(tick, 16);
// do rendering, animation
}
This approach shifts the responsibility of determining the right frame rate for the game from the programmer
to the browser. The browser is almost always more capable of estimating the different variables that this
decision entails. If, for instance, the user opened multiple tabs with resource-demanding WebGL content, the
browser may decide to only allow each of them to display their content at 30 fps instead of 60 fps. This
prevents one window from starving others for resources. Another example, which occurs with tabbed
browsing, happens when the game is running in a tab that is not visible by the user. In this situation, the
game may find that it is only allowed to display one or two frames per second since the browser doesn't want
to waste resources on displaying animation that the user never sees. Such performance optimizations are
naturally browser dependent and the programmer can't rely on them in any way.
Using
requestAnimationFrame()
is currently the recommended method of making animation in HTML5.
Since it doesn't make any guarantees on the time interval between calls to
tick()
, using the ∆T formula is
essential for smooth and platform-independent animation. A call to
tick()
may be deliberately delayed by
the browser due to a global policy, like in the case of an inactive tab, or it can be delayed by other
influences, like garbage collection triggering, or even external influences in the host machine that causes a
slow down. It is up to the code in
tick()
to maintain accurate time measurement for the formula to work.
The first call to
tick()
does nothing but take a sample of the current time by doing:
lastTickTime = new Date().getTime();
Every subsequent call to
tick()
calculates the time that passed from the previous call:
var timeNow = new Date().getTime();
var delta_t = lastTickTime - timeNow;
lastTickTime = timeNow;
lastTickTime
is updated to be used in the next call to
tick()
and from this point on
delta_t
(lowercase t)
is going to be used for updating the animation. This calculated value of
delta_t
is useful for the animation
as long as there are no unexpectedly long delays. A sudden long delay sets a high value to
delta_t
and
causes the animation to jump ahead abruptly, allowing the animation to essentially “run away.” The player
sees the bike at one place on the grid, then suddenly the animation freezes and the next thing he sees
after half a second is the bike a few edges ahead, without a smooth transition. This may even cause the
player to crash and loose the game if he didn't have the chance to make a turn at the right moment. When
we get the call to
tick()
after an unexpectedly long delay, the damage of a frozen animation was already
done and the best we can do now is to avoid further inconvenience to the player. A runaway animation is
avoided by limiting
delta_t
to an upper bound:
if (delta_t > 50) { // milli-seconds
delta_t = 50;
}
