VGA Sprites

Overview

Because there is no hardware sprite system, a sprite is just a rectangle of pixel data the program draws into screen memory. It copies the sprite to the right place, arranges for the transparent parts not to overwrite the background, and restores what was underneath when the sprite moves. All the work falls on the CPU, so sprite size and count trade against frame rate, exactly as on other machines without sprite hardware.

Sprite format

In the linear 256-colour mode 13h a sprite is a chunky pixel block: rows of bytes, one byte per pixel, each byte a palette index, stored left to right then top to bottom. A sprite w pixels wide and h pixels tall is w × h bytes. This is the same format as the screen itself, so a sprite is a small framebuffer that gets copied into the big one.

One palette index is set aside as the transparent colour, the colour key. Pixels of that index mean "leave the background showing" rather than a real colour, so the sprite's outline can be any shape inside its rectangle. Index 0 is the usual choice for the key.

Blitting and the colour key

Drawing a sprite is a blit: copying its rows into the framebuffer at the target position. For a sprite at column x, row y, the first row lands at offset y * 320 + x, and each following row advances 320 bytes, the width of the screen. Because both sprite and screen are chunky, the copy is a straight byte-for-byte move per row.

The colour key turns that copy into a transparent blit. Instead of copying every byte, the routine tests each source pixel: if it equals the key index it is skipped and the screen byte is left alone; otherwise it is written. The result shows the sprite's shape with the background intact around and through it. This per-pixel test is slower than a plain copy, which is why fully opaque blocks are sometimes drawn with a solid copy and only edges use the key.

Masked blits

A faster alternative to testing each pixel is to precompute a mask. The sprite is stored twice: the colour data, and a mask the same shape where each byte is all-ones over transparent pixels and all-zeros over solid ones. The blit reads the screen, ANDs it with the mask to punch a hole where the sprite is solid, ORs in the sprite data, and writes the result. No per-pixel branch is needed, so the inner loop stays tight.

Masked blits cost twice the sprite data and an extra read-modify-write per pixel, but they run at a steady rate whatever the sprite's shape, which suits action games where many sprites move every frame. The background under each sprite is still saved and restored, or the whole scene is redrawn, so the sprite can move without leaving a trail.

Mode-X and page flipping

Mode-X changes how sprites are drawn. In unchained planar mode a sprite is stored plane by plane so that plane-aligned copies write four pixels at once through the card, which is faster than the byte-at-a-time chunky copy. Alignment matters: a sprite drawn at an x position that is a multiple of four keeps the same plane order, so games either restrict sprites to four-pixel steps or keep four pre-shifted copies, one per plane phase.

The larger win is page flipping. Mode-X leaves spare video memory for a second and third screen page. A frame is built entirely off-screen, then the display is pointed at it during the vertical retrace, so the player never sees a half-drawn frame. Sprites move without flicker or tearing, which is hard to achieve in single-page mode 13h where drawing happens on the visible screen.