Sprite Animation Best Practices

Question

I'd like to get a better handle on how people in the real world are handling their animation.

Do you load 1 large image and then draw different rectangles based on the animation frame?

Do you load X image files into an array and draw the item in the array based on the animation frame?

How do you handle having different lengths of animations for various sprites.

Say a character walking takes 4 - 8 frames, and the waves on the beach only take 2 - 3 frames. How would you handle that situation? See Below

Dim Waves(1) as Sprite
Dim Char(5) as Sprite

Sub Animate()
     Frame += 1
     Draw Char(Frame)
     Draw Waves(Frame)
     If Frame = 5 Then Frame = 0
End Sub

Obviously Waves would end up with an out of bounds error.

Or do you have your sprite worry about it's own animation, and not care about the frame at all. Having each sprite know its own animation loop?

Answer 1

The way I've done it in the past is by separating the animation data from animation playback. An Animation can then become basically an array of Frames and a few properties that describe how the animation should behave (if it loops, etc).

I typically load one image and draw pieces of it.

Each Frame of the animation is essentially a rectangle and a length of time. This allows for some frames to display longer than others, which may or may not be something you want. If you want all of the frames in your animation to display for the same length of time, store that in your Animation object.

Anything that needs to play an animation has its own AnimationPlayer which can be pointed to an Animation. The player object takes care of playing the animation and makes the "current frame" available.

The advantage to this for me was that I could have a single instance of an Animation that many objects could point to and be playing different parts at the same time. It was also easy to change animations by simply pointing the AnimationPlayer to a different Animation object and resetting the playback.

Edit: Here's a fairly basic JavaScript implementation of the system described above. I threw it together in a few minutes as a demonstration. "Real" code would have more features. You'll need a modern browser that supports both Canvas and Data URI for it to work, though.

Answer 2

I would have an animation know how many frames it has. Where and how these are stored is relatively irrelevant except for performance issues (like you might want them in the same texture). I would not add 1 to the framecount ever, I would add deltaTime * animSpeed and convert that value to an integer when displaying. This way you can slow down or speed up the animations and are framerate independent.

So a sprite would have an animation which updates itself.

Answer 3

Why not just have a the number of frames for each of your objects stored? Personally I pass the number of frames in the animation to my objects in their constructors, then I have a standard Animate() function which takes in the amount of frames in the animation.

Answer 4

It depends on the implementation. In my engine, I do animation in both Direct3D and DirectDraw.

In DirectDraw I create one big image. It all gets stored in system memory anyway, which eventually comes down to a one-dimensional block of data.

Pros:

• Easy to move between frames. Change the start pointer, add the pitch (the total image width) every y and you're golden.

Cons:

• Can't just copy one frame to the screen, you have to do it manually.

• Giant block of memory. Hustling frames around comes at a penalty.

In Direct3D I use separate textures. This is because I have no idea of the texture limitations of a device so I don't know whether it even supports textures that are the size of the entire image.

Pros:

• You can copy a frame straight to the screen, because they're all separate entities.

Cons:

• Lack of memory alignment.

Answer 5

In my games, I've given my Sprite base class the knowledge about how to draw itself, and all animated elements inherit that knowledge: number and duration of animation frames, position on the screen, etc. The main game loop just iterates through all of the sprites, asking each to draw itself as it sees fit. Seems to work fairly well, and is a little more modular to boot: if you add a new sprite that has a different animation loop (or even more complex: multiple animation states), you don't have to go back and rewrite your Animate() routine to accommodate the additional complexity:

Dim Waves as Sprite
Dim Char as Sprite

Sub Animate()
     Char.update()
     Waves.update()
End Sub

Each time a sprite's update() method gets called, it knows if it should redraw the same frame as last time, move to the next frame in its current animation, change to a new animation, etc.

This has the added benefit of making it a lot easier to adjust the framerate to accommodate differing clock/platform rendering speeds, because the only change is how often you call Animate().