Time-based animation

Live coding video: time-based animation

Hi! This time I will talk to you about what is called time-based animation. Here, we have got a simple example of a bouncing rectangle and the animation is done in an animationLoop that is called 60 times per seconds using the requestAnimationFrame. We clear the rectangle that corresponds to the canvas area, and we add a fixed increment to the x position.If x is just bounces on the side, we just reverse the speed.The speed is a fixed value of 3px per frame. What is happening if we run this application on a low end-smartphone or a Raspberry Pi, a low end-computer with a not very powerful GPU? We can simulate what would happen by just adding a big loop here to slow down artificially the animation.This is what I have done here. Here I count up to 70 millions in the loop. So this takes time and slows down the animation. The rectangle is just moving 3px every frame, but as the the frame rate drops down a lot, the actual speed on the screen of the rectangle is much slower than what I have got here. And here I added also a loop so this is a normal speed. What we can do in order not to have the speed going down? We will compute the time between two consecutive frames. So here I am using the date object from JavaScript to get the current time and I compute a delta that is a difference between the current time and the time at the previous animation. So the delta is the number of milliseconds elapsed since the last animation. And then we will compute the distance instead of using 3px per frame, the number of pixels we move the rectangle will increase if the time between frames increases. So we have got a function that is explained in the course that will compute the distance taking into account the time elapsed since the last frame and the speed we want to achieve in pixels per seconds, not in pixels per frames, but in pixels per seconds. This time, we are adding the increment but it is adjusted at each frame of animation. Here is an example that I slow down and if I change the time that this will take you can see that it goes from smooth to a bit jerky… to really jerky, but the speed on the screen is the same.It takes the same time to bounce from on side to another.This is what is done in real games. I wanted to show you also another thing, Instead of using the date object from JavaScript that gives the time in milliseconds, but as we are animating at 60 times per seconds, having an high resolution timer that has a sub-millisecond accuracy is much better and was asked by game developers.The callback function that is called when you use requestAnimationFrame can have an extra parameter that we have not used until now.So you can add a parameter here that will be a high resolution time.And then you compute the delta using this time that is automatically passed to you by the requestAnimationFrame API. Here, I added this technique to the game framework.So, I am in the mainLoop from the last example we used with the game framework for moving the small monster using the keys. I artificially slowed down the animation. So if I do this, I have got 8 frames per seconds, and you can see that the monster moves, but it jumps with larger steps between two consecutive frames. If I remove this artificial part of the code that slows down the animation, I go up to 60 FPS and I have got a smooth animation.That means that this example will be usable on many different devices as the animation will be adapted depending on the power of the device. So this is time-based animation.

Let's study an important technique known as "time-based animation", that is used by nearly all "real" video games.

This technique is useful when:

Your application runs on different devices, and where 60 frames/s are definitely not possible. More generally, you want your animated objects to move at the same speed on screen, regardless of the device that runs the game.

For example, imagine a game or an animation running on a smartphone and on a desktop computer with a powerful GPU. On the phone, you might achieve a maximum of 20 fps with no guarantee that this number will be constant; whereas on the desktop, you will reliably achieve 60 fps. If the application is a car racing game, for example, your car will take 30s to make a complete loop on the race track when running on a desktop, whilst on a smartphone it might take 5 minutes.

The way to address this is to run at a lower frame-rate on the phone. This will enable the car to race around the track in the same amount of (real) time as it does on a powerful desktop computer.

Solution: you need to compute the amount of time that has elapsed between the last frame that was drawn and the current one; and depending on this delta of time, adjust the distance the car must move across the screen. We will see several examples of this later.

You want to perform some animations only a few times per second. For example, in sprite-based animation (drawing different images as a character moves, for example), you will not change the images of the animation 60 times/s, but only ten times per second. Mario will walk on the screen in a 60 fps animation, but his posture will not change every 1/60th of second.
You may also want to accurately set the framerate, leaving some CPU time for other tasks. Many games consoles limit the frame-rate to 1/30th of a second, in order to allow time for other sorts of computations (physics engine, artificial intelligence, etc.)

How to measure time when we use requestAnimationFrame?

Let's take a simple example with a small rectangle that moves from left to right. At each animation loop, we erase the canvas content, calculate the rectangle's new position, draw the rectangle, and call the animation loop again. So you animate a shape as follows (note: steps 2 and 3 can be swapped):

erase the canvas,
draw the shapes,
move the shapes,
go to step 1.

When we use requestAnimationFrame for implementing such an animation, as we did in the previous lessons, the browser tries to keep the frame-rate at 60 fps, meaning that the ideal time between frames will be 1/60 second = 16.66 ms.

Example #1: no use of time-based animation

Online example at JSBin

<!DOCTYPE html>

<head>

<title>Small animation example</title>

var canvas, ctx;

var width, height;

var x, y;

var speedX;

// Called after the DOM is ready (page loaded)

function init() {

// init the different variables

canvas = document.querySelector("#mycanvas");

ctx = canvas.getContext('2d');

width = canvas.width;

height = canvas.height;

x=10; y = 10;

// Move 3 pixels left or right at each frame

speedX = 3;

// Start animation

animationLoop();

}

function animationLoop() {

// an animation involves: 1) clear canvas and 2) draw shapes,

// 3) move shapes, 4) recall the loop with requestAnimationFrame

// clear canvas

ctx.clearRect(0, 0, width, height);

ctx.strokeRect(x, y, 10, 10);

// move rectangle

x += speedX;

// check collision on left or right

if(((x+5) > width) || (x <= 0)) {

// cancel move + inverse speed

x -= speedX;

speedX = -speedX;

}

// animate.

requestAnimationFrame(animationLoop);

}

</script>

</head>

</canvas>

</body>

</html>

If you try this example on a low-end smartphone (use this URL for the example in stand-alone mode) and if you run it at the same time on a desktop PC, it is obvious that the rectangle moves faster on the desktop computer screen than on your phone.

This is because the frame rate differs between the computer and the smartphone: perhaps 60 fps on the computer and 25 fps on the phone. As we only move the rectangle in the animationLoop, in one second the rectangle will be moved 25 times on the smartphone compared with 60 times on the computer! Since we move the rectangle the same number of pixels each time, the rectangle moves faster on the computer!

Example #2: simulating a low-end device

Here is the same example to which we have added a loop that wastes time right in the middle of the animation loop. It will artificially extend the time spent inside the animation loop, making the 1/60th of second ideal impossible to reach.

Try it on JsBin and notice that the square moves much slower on the screen. Indeed, its speed is a direct consequence of the extra time spent in the animation loop.

function animationLoop() {

...

for(var i = 0; i < 50000000; i++) {

// slow down artificially the animation

}

...

requestAnimationFrame(animationLoop);

}

Page updated

Google Sites

Report abuse