# How to slow down a sprite that updates every frame?

I am going through a Allegro 5 tutorial which has a game loop.

There is also a variable "active" which determines if a key is being held down. Thus if the left key is being held down active is on and it begins looping through the row on the sprite sheet that corresponds to moving left.

The problem is that this logic is checked everytime the loop is performed thus at approximately 60 fps the three images that are used to do the left walking animation cycle round super fast which means my character looks like it is in a rush.

Total beginner question: so what is the correct way to slow down the transition between sprites so that the walking looks like it is done at a moderate pace.

Here is the code used to transition across the sprite between the three different phases of the person walking:

        if (active) {
sourceX += al_get_bitmap_width(player) / 3;
} else {
sourceX = 32;
}

if (sourceX >= al_get_bitmap_width(player)) {
sourceX = 0;
}


I can kind of guess what it should be in plain English: update sourceX only every certain part of a second but I can't think of how to put this into code.

You're on the right track; you just need to throw in a system to regulate the timing with which the sprite is updated. The exact model you use is up to you - essentially whatever concept you like working with. In the example I will provide you can specify the speed of the animation in frames per second (independent from the FPS of your game, of course). Alternatives would be animation speed on a 0 to 1+ scale, or directly specifying the amount of time between each animation swap.

With the 'frames per second' method, you can declare your animation speed as follows:

float animationSpeed = 5.0f;


Here I've chosen to run the animation at 5 frames per second. Whatever rate is chosen, it means that every 1.0f / animationSpeed seconds, the sprite's frame has to be updated, giving the following:

float animationUpdateTime = 1.0f / animationSpeed;


You also need to keep track of the time since your last update:

float timeSinceLastFrameSwap = 0.0f;


And every frame you will add deltaTime to this, assuming that you already have a system in place for obtaining the deltaTime of the frame:

timeSinceLastFrameSwap += deltaTime;


Note that you'd only do this when active is true - when your sprite is animating. When timeSinceLastFrameSwap exceeds animationUpdateTime, you can increase sourceX and reset timeSinceLastFrameSwap, so the whole update would look like this:

if (active) {
timeSinceLastFrameSwap += deltaTime;
if (timeSinceLastFrameSwap > animationUpdateTime) {
sourceX += al_get_bitmap_width(player) / 3;
timeSinceLastFrameSwap = 0.0f;
}
if (sourceX >= al_get_bitmap_width(player)) {
sourceX = 0;
}
} else {
sourceX = 32;
timeSinceLastFrameSwap = 0.0f;
}


Happy coding!

• Thanks for taking the time to show the slow'n'right method. I've had a good look and think I understand. Does that mean when active is false I should set the timeSinceLastFrameSwap back to zero. Or is this not necessary? – going Nov 21 '12 at 5:45
• @xiaohouzi79 Good catch :). That is correct, you probably want to set it back to zero. I've updated the answer. – kevintodisco Nov 21 '12 at 5:47
• Great, I've got this to work. One thing to note, (forgive the poor terminology), the only delta I can work on is using events.timer.count which uses ticks. This means that the delta between each ALLEGRO_EVENT_TIMER event is usually 1. Because in the example above you had 1.0f / animationSpeed this threw me. I am now just using a single variable animationSpeed set at 5 (for now) which triggers the step every 5 ticks. I assume this is right now. Cheers! – going Nov 21 '12 at 9:46

You can add a local variable i, which you will increase each every frame i++. Then you can update your animation each frame when i mod 10 == 0 to update animation at 6fps slower.

EDIT: This is not recommended solution for the most of the cases. Usually your animation should depend on time, not the render speed. See the other answer for explanation and details.

• This is not recommended. This makes your animations framerate-dependent, which is not at all desirable. You should always make sure that updating elements are time-dependent. – kevintodisco Nov 21 '12 at 5:23
• @ktodisco: You are right. However sometimes you need quick'n'dirty instead of slow'n'right. Let's just present these both alternatives :) – Kromster says support Monica Nov 21 '12 at 5:30
• @KromStern Fair enough. It does get the job done :) – kevintodisco Nov 21 '12 at 5:33