Frame animation is the flick-book trick: show a series of still drawings one after another, quickly enough, and a character walks, a wing beats, a door swings open. Every moving thing in a 2D game works this way. What made it a craft on 8-bit machines was the cost. Each drawing took memory, and on a computer without sprite hardware each change of drawing also took time to draw, so programmers and artists rationed their frames like any other resource.
Players noticed the result. Reviewing Domark’s Gladiator for the Spectrum at Christmas 1985, a CRASH reviewer complained that the thumb that comes out when a fighter loses “is pretty rotten — it’s so-o-o-o slow and has about three frames of animation”. By the end of the decade frame counts were a selling point. CRASH previewed Gazza’s Super Soccer in August 1989 with “40-50 frames of animation making up each player”, and an advertisement in ZZAP!64 that September promised “More than 1300 Frames of animation” for the boxing game The Champ.
Drawings, order and timing
An animation has three parts: the drawings, the order to show them in, and how long each one stays on screen. The screen is redrawn 50 times a second on a PAL machine and 60 on an NTSC one, but few characters change drawing that often. A program usually holds each drawing for several screen frames and counts frames to decide when to move on; Sprite Animation shows that counter in code for the C64, Spectrum, NES and Amiga.
The order does not have to use each drawing once. A walk can return through its middle drawings, and a sequence can repeat a frame to stretch a pose. Jonathan Hare, explaining the example game in Sensible Software’s Shoot ’em Up Construction Kit to ZZAP!64 readers in February 1988, pointed out that its kneeling enemies and its sheriff “use different animation frames more than once in their animation sequence”, which he called “another useful and effective sprite-conserving technique”.
What a drawing costs
Commodore 64
A C64 hardware sprite is 24×21 pixels, 63 bytes, and each drawing occupies a 64-byte block: “one more byte is needed as a place holder at the end of each sprite”, in the words of the Programmer’s Reference Guide. Changing drawing is cheap, because the video chip finds each sprite’s shape through a one-byte pointer, so a single write swaps the picture. Memory is the limit: the video chip “can access (‘see’) 16K of memory at a time”, and every frame of every character has to fit in it alongside the screen and character set.
The VIC-II also cannot mirror a sprite, so a character that faces both ways needs every drawing twice. Hare’s guide shows how a game written with the kit dealt with that. Its kneeling enemies were drawn once and copied: “I used copy and mirror to get them facing both ways”. Its player characters walked on just two frames, and for diagonal movement he “cheated and used the forward and backward sprites for the diagonals”, because “it does conserve a lot of free sprites”.
ZX Spectrum
The Spectrum has no sprites at all. A moving character is a bitmap that the program draws into screen memory, erasing the old drawing and drawing the next, so every frame costs drawing time as well as memory.
Matthew Smith’s Manic Miner (1983) shows how far a small budget can go. Its hero, Willy, has eight drawings in all, 16×16 pixels and 32 bytes each: four facing right and four facing left, 256 bytes for the lot. The four drawings for each direction sit progressively further across their 16-pixel box, and the animation frame doubles as Willy’s position. Walking right moves him on to the next drawing; only when he steps past the fourth does his position on the character grid move along, with the frame going back to the first. The same four numbers that move his legs move him across the screen.
NES
The NES can flip a sprite in hardware: in each sprite’s attribute byte, bit 6 flips it horizontally and bit 7 vertically. One set of drawings serves both directions, which halves the cost of a character that turns round. Sprite Animation covers the details, including the extra step needed for a character built from several sprites.
Animation as data
Writing separate code for each animated object soon fills memory, so programs described their animations as data instead. Jeff Minter explained the approach in his Iridis Alpha development diary for ZZAP!64 in August 1986. His attack waves are run by ACONT, “an interpreter for my own wave language, allowing me to describe, exactly, an attack wave in about 50 bytes of data”, because “even with 64K you can run outta memory pretty fast” with code for every wave. Each wave’s data records “what each alien looks like, how many frames of animation it uses, speed of that animation, colour”, along with its speed, acceleration and whether it homes in on a target.
The Shoot ’em Up Construction Kit gave its users the same kind of table, and Hare showed how to tie behaviour to it. To make an enemy fire each time its animation reaches the first frame, set its firing rate to its animation speed multiplied by its number of frames. The shot then leaves at the same point in every cycle.
Many more frames
When memory grew, some developers spent it on frames. Jordan Mechner traced the movements for Prince of Persia from video of his brother, and Delphine’s Flashback sold its hero on 24 frames a second; Rotoscoping tells those stories.
Sources
- CRASH, issue 24, Christmas 1985/86: review of Gladiator (Domark, Spectrum).
- CRASH, issue 67, August 1989, p. 28: preview of Gazza’s Super Soccer.
- ZZAP!64, issue 53, September 1989: advertisement for The Champ.
- ZZAP!64, issue 16, August 1986, pp. 50–51: “The Daily Llama”, Jeff Minter’s Iridis Alpha diary.
- ZZAP!64, issue 34, February 1988, pp. 54–57: “The Sensible Guide to” the Shoot ’em Up Construction Kit, by Jonathan Hare.
- Commodore 64 Programmer’s Reference Guide (Commodore, 1983): the VIC-II’s 16K view of memory; sprite chapter, 24×21 dots, 63 bytes, and the extra place-holder byte.
- Wireframe, issue 37, April 2020: Jordan Mechner on filming his brother for Prince of Persia. Amiga Format, issue 44, March 1993: Flashback’s hero “animated at a rate of 24 frames per second”.
- Richard Dymond, The complete Manic Miner RAM disassembly (SkoolKit; web, secondary): Willy’s sprite graphics at
8200, his animation frame at8069, the drawing routine at927Fand the movement routine at8BDD. https://skoolkid.github.io/manicminer/ - NESdev wiki, “PPU OAM” (web, secondary): the horizontal and vertical flip bits. https://www.nesdev.org/wiki/PPU_OAM