Move a character across a bitmap screen and the program has to rub out the old picture, put back whatever was behind it and draw the character again one step along, every frame, for every moving thing. A sprite hands that job to the video chip. The program says what the object looks like, what colour it is and where it goes; the chip draws it over the background as the picture goes out to the television, and leaves the screen memory untouched. Moving it means changing a pair of coordinates.
Commodore’s Programmer’s Reference Guide sold the idea to Commodore 64 owners in exactly those terms: “all you have to do is tell a sprite ‘what to look like,’ ‘what color to be,’ and ‘where to appear.’ The VIC-II chip will do the rest!” It even claimed that “because the sprites are maintained by hardware, it is even possible to write a good quality game in BASIC!”
The catch was that every chip set its own limits: how many sprites, how wide, how many colours, and above all how many on a single line of the picture. Those numbers decided what a game could put on screen, and programmers spent years getting round them.
Where the word came from
Texas Instruments used the word in the data manual for its TMS9918 video chip, which went into the TI-99/4A, the ColecoVision and MSX computers. Its glossary defines a sprite as “an object whose pattern is relative to a specified X, Y coordinate and whose position can therefore be controlled by that coordinate with a positional resolution of one pixel”. Karl Guttag, who designed the chip’s sprite logic, has written that “the 9918 coined the word ‘Sprites’”, and credits the name to his colleague Dave Ackley.
Other chips had the same idea under other names. Atari’s TIA in the 2600 has two “players”, two “missiles” and a “ball”; the Atari 400 and 800 kept the player and missile names. MOS Technology’s data sheet for the Commodore 64’s VIC-II calls its eight objects “movable image blocks (MIBs)”. Commodore’s own manual for the machine called them sprites. Nintendo’s manuals, from Ricoh’s specification for the NES chip to the SNES developer manual, say “objects” (OBJ).
Fast facts
- What it is: a small picture drawn by the video chip over the background at a position set by the program.
- What it saves: erasing, restoring and redrawing screen memory for every moving object, every frame.
- What it costs: a fixed number of sprites, a fixed size and colour depth, and a limit on how many can share one line.
- Other names: players, missiles and ball (Atari); movable image blocks (MOS); objects or OBJ (Nintendo); line sprites (SNK).
- Without them: software sprites, drawn by the processor into screen memory, as on the ZX Spectrum.
Machine by machine
| Machine and chip | Sprites | On one line | Size | Colours per sprite |
|---|---|---|---|---|
| Atari 2600 (TIA, 1977) | 2 players, 2 missiles, 1 ball | all five | player 8 pixels wide; missiles and ball 1 pixel, stretchable to 2, 4 or 8; height set line by line | 1; each missile shares its player’s colour, the ball the playfield’s |
| Atari 400/800 (ANTIC and CTIA/GTIA) | 4 players, 4 missiles | all | player 8 pixels wide, missile 2; each a strip the height of the screen | 1 |
| TMS9918 (MSX, ColecoVision, TI-99/4A) | 32 | 4 | 8×8 or 16×16, doubled to 16×16 or 32×32 by magnification | 1 |
| Commodore 64 (VIC-II) | 8 | 8 | 24×21, doubled in either direction | 1 (hi-res) or 3 (multicolour, two of them shared), plus transparent |
| NES (PPU) | 64 | 8 | 8×8 or 8×16 | 3 plus transparent, from 4 sprite palettes |
| Master System (VDP) | 64 | 8 | 8×8 or 8×16 | 15 plus transparent, from the second 16-colour table |
| Amiga (Denise) | 8 channels, each reusable down the screen | 8 | 16 pixels wide, any height | 3 plus transparent; 15 plus transparent for an attached pair |
| Game Boy | 40 | 10 | 8×8 or 8×16 | 3 plus transparent, from 2 palettes |
| Mega Drive (VDP) | 80 (64 in the 256-pixel mode) | 20 (16), and no more than 320 (256) pixels | 8×8 to 32×32 in 8-pixel steps | 15 plus transparent, from 4 palettes |
| SNES (PPU) | 128 | 32, and no more than 34 slices 8 pixels wide | two sizes per frame, from 8×8 up to 64×64 | 15 plus transparent, from 8 palettes |
| Neo Geo | 380 | 96 | 16 pixels wide, up to 512 tall | 15 plus transparent, from 256 palettes |
The table hides as much as it shows. The Atari machines’ players are not really objects at all: on the 2600 the program writes a player’s shape into an 8-bit register line by line as the beam comes down the screen, and on the 400 and 800 each player is a strip of memory the full height of the screen, so moving one up or down means moving its bytes. The Neo Geo’s 380 are the opposite extreme. A Neo Geo “line sprite” is a column of 32 characters of 16×16 dots, and the machine has no scrolling tile layer for its scenery: backgrounds are built from sprites too, which is why it needs so many.
Programming a sprite
Whatever the chip, a program sets up the same few things for each sprite:
| Setting | What it does |
|---|---|
| Position | X and Y on the screen |
| Shape | which pattern to draw, usually by pointer or tile number, so changing it animates the sprite |
| Enable | whether the sprite is shown at all |
| Colour | the sprite’s colour register or palette |
| Priority | in front of or behind the background, and which sprite wins when two overlap |
| Flip | horizontal or vertical mirroring, on the chips that have it |
Where the settings live differs from chip to chip. The VIC-II keeps them in its own registers. The NES, Master System, Mega Drive, SNES and Game Boy keep a table of entries in memory, a few bytes per sprite, which the chip scans for each line; NES and Game Boy programs build the table in ordinary RAM and copy it across in one go during vertical blank.
The Commodore 64
Each of the VIC-II’s eight sprites is a 24×21 block of 63 bytes with its own colour, an optional multicolour mode and 2× magnification in either or both directions. Multicolour halves the horizontal resolution to 12 double-width dots and gives three colours plus transparent: the sprite’s own colour and two shared by all eight sprites, set in $D025 and $D026. Priority between sprites is fixed, sprite 0 in front and sprite 7 behind; priority against the background is one bit per sprite in $D01B. The chip reports collisions between sprites in $D01E and between sprites and the background in $D01F. The guide already pointed beyond eight: “More sprites can be displayed using RASTER INTERRUPT techniques”, the trick that became sprite multiplexing.
The Amiga
Commodore’s Amiga Hardware Reference Manual describes sprites “16 pixels wide and any number of lines high”, with “three colors” and transparent. The eight share their colours in pairs, and a pair can be attached, laid one over the other, to give 15 colours plus transparent at the cost of two channels. Each channel’s data list can also describe several sprites one after another down the screen, “thus, you are not limited to having only eight sprites on the screen at the same time”. Programs that needed more or bigger objects drew them with the blitter instead (see BOBs).
The limit that shaped games: sprites per line
A chip draws a line of the picture at a time, and it has to fetch the pixels of every sprite on that line before the beam gets there. It does that with a fixed number of slots, and when they are full the rest of the sprites on that line are not drawn. The TMS9918 manual puts it plainly: “Only four sprites can be active on any horizontal line. Additional sprites on a line will be automatically made transparent for that line.”
| Chip | Per line | Which sprites are dropped |
|---|---|---|
| TMS9918 | 4 | the fifth and later; a status bit and the number of the fifth sprite report it |
| NES | 8 | those later in the sprite table; the overflow flag is unreliable |
| Master System | 8 | lines with nine or more “not displayed properly”; a status bit reports it |
| Game Boy | 10 | the rest are not drawn |
| Mega Drive | 20 (16 in the 256-pixel mode) | lower priority first; wide sprites use up the pixel budget sooner |
| SNES | 32, and 34 slices of 8 pixels | two separate limits, reported by two status bits |
| Neo Geo | 96 | SNK’s manual says sprites “from the highest priority will start missing” |
The Commodore 64 is a different case. Its eight sprites can all share one line, so the limit is the total: a ninth object needs a ninth sprite, and there is none.
Games had two ways round the limit. One was to reuse sprites down the screen, which works on the C64 and Amiga where the problem is the total rather than the line (see sprite multiplexing). The other, on the NES, Master System and SNES, was to change the order of the sprite table every frame, so that a different sprite dropped out each time and every object was visible some of the time. That is sprite flicker. Nintendo’s own SNES manual recommends it as “virtual OBJs”, and warns that the sprites “will flash every frame”.
Collision detection
Some chips also report when sprites touch, which saves the program from comparing coordinates.
| Machine | What the hardware reports |
|---|---|
| Atari 2600 | every overlap between each pair of objects and the playfield, latched for the program to read |
| TMS9918, Master System | one status bit: two sprites have touched |
| Commodore 64 | which sprites have touched another sprite ($D01E) or the background ($D01F) |
| Amiga | collisions between sprite pairs, sprites and playfields, and the two playfields, in CLXDAT |
| NES | only sprite 0 against the background |
| Mega Drive | one status bit: non-zero pixels of two sprites have met |
A single bit says that something collided, not what, so most games still checked their own object rectangles (see collision detection). The NES’s one flag was put to a different use. Bit 6 of $2002 is set when an opaque pixel of sprite 0 is drawn over an opaque background pixel, which tells the program where the picture has got to. Super Mario Bros. places sprite 0 at the bottom of its status bar, waits for the flag and then changes the scroll, so the score stays still while the world moves (see the PPU).
Scaling and rotation
Most home sprite chips could only double a sprite’s size, if that. Smooth scaling was an arcade speciality, from Sega’s Turbo in 1981 to its “Super Scaler” boards for Hang-On and Out Run. At home the Neo Geo could shrink its sprites and the Atari Lynx scale them. The SNES’s famous Mode 7 rotates and scales a background layer, not sprites. See Sprite scaling and Mode 7.
Without hardware sprites
The ZX Spectrum has no sprites: its display is a bitmap with a separate block of colour attributes, and anything that moves has to be drawn into screen memory by the Z80 (see screen memory). The Oliver twins described how their Dizzy games did it. The first game drew Dizzy with exclusive-OR, “printed once to appear and a second time to make him disappear”. It was fast, but “when he walked in front of other graphics, he’d appear a little messy, and could be difficult to see”. By Fantasy World Dizzy they used masked sprites: save the patch of screen underneath, cut a Dizzy-shaped hole with a mask, draw Dizzy into it, and copy the saved patch back when he moves on. The mask doubled the memory: each frame of Dizzy took 60 bytes plus 60 for its mask, and his 39 frames about 4.5K. Dizzy still took on the colour attributes of whatever he stood in front of, “like a chameleon”.
A software sprite can be any size and there is no limit to how many, but every one costs processor time to draw and erase, every frame. Programs that wanted smooth movement without flicker often drew into a second copy of the screen and copied it across in one go (see double buffering). The Amiga used both approaches at once: hardware sprites for a few objects, the blitter for the rest.
Sources
- Texas Instruments, TMS9918A/TMS9928A/TMS9929A Video Display Processors Data Manual (November 1982): glossary, p. 1-3 (definition of a sprite); section 2, pp. 2-15 to 2-16 (32 sprite planes, sizes, four per line, the fifth-sprite flag), pp. 2-24 to 2-26 (sprite pattern formats and magnification, the four highest-priority sprites displayed).
- Karl Guttag, “Texas Instruments 99/4A and TMS9918 History”, KGOnTech, 28 June 2017, and “TMS9918, The First Sprite Chip – Presentation at VCF SouthWest”, KGOnTech, 1 July 2025 (web, secondary): his work on the sprite logic and Dave Ackley’s naming of the sprite. https://kguttag.com/2017/06/28/texas-instruments-994a-and-tms9918-history/ and https://kguttag.com/2025/07/01/tms9918-the-first-sprite-chip-presentation-at-vcf-southwest/
- Atari, Stella Programmer’s Guide (Steve Wright, 1979): section 3 (colour-luminance registers shared by player and missile, and by playfield and ball), sections 6.0–6.3 (the five movable objects, missile and ball widths, 8-bit players drawn line by line), section 10 (collisions).
- Atari, De Re Atari (1982), section 4, “Player-Missile Graphics”: four players 8 bits wide, 2-bit missiles, one colour per player, vertical movement by moving the player’s bytes.
- MOS Technology, 6567 VIC-II preliminary data sheet: “movable image blocks (MIBs)”.
- Commodore, Commodore 64 Programmer’s Reference Guide (1982): p. 131 (sprites maintained by the VIC-II, eight at a time, more with raster interrupts, games in BASIC), pp. 135–136 (multicolour sprites and
$D025/$D026), pp. 143–144 (priority,$D01B, collision registers$D01Eand$D01F). - Ricoh, development specification for the RP2C02, 1982 (unpublished): 64 objects per screen and eight per line in four-byte entries scanned in index order; 8×8 or 8×16; four colour sets with colour 0 transparent; the collision flag for object 0 only.
- Sega, Software Reference Manual for the Sega Mark III (1986), pp. 5 and 8: 64 sprites, 8×8 or 8×16, colours from the second 16 entries of colour RAM, eight per line, the nine-sprite and collision status bits. Charles MacDonald, “Sega Master System VDP documentation”, SMS Power (web, secondary): sprite colour 0 is transparent. https://www.smspower.org/Development/Documents
- Commodore-Amiga, Amiga Hardware Reference Manual (1985), chapter 4, “Sprite Hardware”, pp. 93–94 and 117–119: eight DMA channels, 16 pixels wide and any height, three colours plus transparent, reuse within a field, attached sprites with 15 colours.
- Nintendo, Game Boy Programming Manual, version 1.1, p. 18 and the OBJ palette registers: 40 objects, ten per line, 8×8 or 8×16, two object palettes of three shades plus transparent.
- Sega, Genesis Software Manual (© 1989 Sega of Japan, revised 1992): Technical Overview (1 to 4 cells square, 80 sprites, 20 on a line, four 16-colour palettes); pp. 56–57, “Sprite’s display capacity” (64 or 80 sprites, 16 or 20 per line, 256 or 320 dots per line); the VDP status register (sprite overflow and collision bits).
- Nintendo, Super NES Development Manual, Book I: chapter 2, “OBJ” (128 objects, four sizes of which two per frame, eight 16-colour palettes); chapter 20, “33’s Range Over” and “35’s Time Over”, and virtual OBJs.
- SNK, Neo-Geo Hardware Specification (1989), Hardware pp. 3–4: the 3D-LINE SPRITE of 32 characters of 16×16 dots, 380 on screen and 96 on a line, 15 colours per character; Software Development p. 5: backgrounds built from line sprites, and which sprites go missing over 96.
- Commodore-Amiga, Amiga Hardware Reference Manual (1985), chapter 7: the collision register
CLXDAT(p. 208). - NESdev Wiki, “PPU OAM” and “PPU scrolling” (community reference, web, secondary): the sprite 0 hit and its use for the Super Mario Bros. status bar. https://www.nesdev.org/wiki/PPU_OAM
- Scaling: MAME source,
src/mame/sega/turbo.cpp(Sega’s Turbo, 1981); Edge issue 9, June 1994, pp. 45–50 (Sega’s Super Scaler games); SNK, Neo-Geo Hardware Specification (sprite reduction); ACE issue 31, April 1990 (the Lynx’s hardware scaling); Nintendo, Super NES Development Manual, Book I (rotation and scaling for background mode 7 only). The Sprite scaling entry gives the details. - Andrew and Philip Oliver, “Squeezing the ZX Spectrum”, Wireframe issue 19, July 2019, pp. 35–36: XOR and masked sprites in the Dizzy games, the memory each frame took.