Return to Table of Contents

Animation

Both sprite tiles and background plane tiles can be animated to give the appearance of some change, typically motion. For example, consider the running animation of the player character in Gunstar Heroes:

The character is animated from just six frames, seen here:

In this example, each animation frame is displayed for eight display frames at a time, so the entire running animation takes 48 display frames to complete one cycle. Since the game runs at 60 frames per second (fps), one animation cycle takes a bit less than one second. It’s important to distinguish between animation frames and display frames this way. Although the character is animated at slightly more than 7 fps, the display is still running at 60 fps—as evident by the smooth scrolling of the screen and the smooth movement of the sprites.

The player character is animated at ~7 fps, but the sprites that make up the character still move across the screen at 60 fps. The following example has been slowed down to 1/10^th speed to show this:

The character moves one pixel across the screen every frame, even though the animation frame only changes every eight frames. This is probably obvious to most people, but I wanted to point out that the animation frame rate is disconnected from the VDP’s ability to move sprites around the screen at 60 fps.

Here is another example, this time of the zako enemy from Gunstar Heroes:

This character is animated with just four animation frames that change every 12 or 13 display frames:

Animation is created by switching the displayed tile from one frame to the next. In many cases, to accomplish this, all of the animation frames are loaded into VRAM at once, and then the sprite attribute table is updated every however-many-frames to reference a different tile. Since VRAM space is very limited, developers are typically restricted in how many frames of animation they can give a character.

However, rather than load all of the animations into VRAM at once, there is another technique that is often used for the main player character. Since it’s visually appealing and often necessary from a gameplay standpoint to have a player character with a lot of animation, rather than updating the sprite attribute table to point to new tiles, developers can instead stream new tiles into VRAM at the same location and keep the sprite table unchanged. Only a relatively small number of tiles can be loaded into VRAM each frame, so this technique is usually limited to just the player character.

Both of these techniques can be seen in the following clip, which shows a section of VRAM to the right of the game screen:

The tiles for the player character are shown towards the bottom of the VRAM display, just above the row of letters. As the character moves, new tiles are streamed into VRAM on-the-go at the same memory location. Using this technique, the entire complex range of animations can be fit into just ~20 tiles.

Now, look at the top half of the VRAM display. There are approximately 13 rows of 30 tiles each for the enemy zako characters (the selected display palette shows their legs as green rather than the red of the on-screen characters). These tiles are static; they do not stream into VRAM like the player character’s tiles. In total, there are almost 400 tiles stored in VRAM at all times to display the zako and their animations. Since each tile is 32 B, the zako tiles take a whopping 12 KB of the 64 KB of available VRAM (nearly 20%!).

Hopefully clear from this last point is the fact that complex, high-frame-rate animation is severely restricted by VRAM availability. Designers must carefully plan character designs around how to get by with the least amount of animation possible.

The examples so far have shown sprites, but plane tiles can be animated as well. In this example, look at the animation at the top of the screen in the foreground trees and at the bottom of the screen in the grass:

It’s possible to update the plane pattern table to reference new tiles in VRAM, although in this example tiles are being streamed into VRAM at the same location (the same technique shown above for the Gunstar Heroes player character). Streaming tiles into VRAM simplifies the process, since it’s not necessary to keep track of which tile entries to update in the plane table.

Animation doesn’t always involve changing the displayed tile itself. In the background of the first stage of Sonic the Hedgehog, for example, only the color palette is being changed every few frames:

The tiles remain the same, but the color palette shifts through four colors to give the impression of movement.

A lot of visually impressive effects on the Mega Drive are actually the result of straightforward animation. Pre-rendered tile animation can be used to create convincing scaling, rotation, and 3D effects that the VDP does not natively support. Consider the following example of the mid-stage boss Bravoo Man from Gunstar Heroes:

The 3D effect on Bravoo Man is impressive and well-designed. How is it done? The entire character is made using only these sprite tiles:

Here are the body sprites animated:

There aren’t any textured polygons or other fancy effects being done. Each segment of the body is simply a sprite that cycles through a six-frame animation. The effect is so convincing because the sprite segments move in relation to each other at a smooth 60 fps. The most impressive aspect of the boss is the calculations driving the complex movement of each segment relative to the others and the interaction of that movement with the sprite animation producing the 3D appearance.

Next: Multi-Jointed Characters

Return to Table of Contents

List of Effects:

1. Introduction
2. Full-Screen Scrolling
3. Row / Column Scrolling
4. Line Scrolling
5. Animation
6. Multi-Jointed Characters
7. Tilting / Rotation
8. Scaling
9. Shadow and Highlight
10. Transparency
11. Silhouette
12. Palette Swapping
13. Vertical Scaling
14. Sprite Raster Effects

Want to post a comment? You can do so here.