Sprites

Sprites are graphical objects handled specially by video hardware — characters, projectiles, items, anything that needs to move without affecting the background. Hardware sprites mean the CPU doesn’t have to erase and redraw moving objects; the video chip composites them with the background each scanline, treating sprite memory as a separate layer that overlays the playfield.

The word is Texas Instruments’. The TMS9918 data manual 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”. Other chips had the same idea under other names: Atari’s TIA (1977) has two “players”, two “missiles” and a “ball” that move in front of the playfield, and MOS’s 6567 VIC-II data sheet calls its eight objects “movable image blocks (MIBs)” — Commodore’s own Programmer’s Reference Guide switched to “sprite”. Subsequent generations refined the idea: more sprites, larger sprites, more colours, more capabilities (collision detection, scaling, rotation).

Fast facts

Definition: Hardware-supported moveable graphics, composited with the playfield by the video chip.
Advantage: CPU offload — no per-frame redraw, no background corruption.
Limitations: Per-platform count, size, colour, and per-scanline limits.
Names: players, missiles and ball (Atari TIA); sprites (TI TMS9918); movable image blocks (MOS VIC-II data sheet).

Platform comparison

Platform	Total sprites	Per scanline	Size	Colours per sprite
Atari 2600	5 (“players” + missiles + ball)	All	8 px wide × variable	1 + transparent
C64 (VIC-II)	8	8	24×21 fixed	3 + transparent (multicolour) or 1 + transparent (hi-res)
NES (PPU 2C02)	64	8	8×8 or 8×16	3 + transparent
Master System (VDP)	64	8	8×8 or 8×16	1 colour from a 16-colour subpalette
Game Boy (PPU)	40	10	8×8 or 8×16	3 + transparent
Amiga (Denise)	8 hardware	8	16 px wide × variable height	3 + transparent (single) or 15 + transparent (attached pair); BOBs add unlimited via Blitter
Mega Drive (VDP)	80	20	8×8 to 32×32 in 8-pixel multiples	15 + transparent
SNES (PPU)	128	32	8×8 to 64×64	15 + transparent
Neo Geo MVS	380+	~96	16×16 to 16×512	15 + transparent

The trend across generations: more sprites, larger sprites, more colours, fewer per-scanline limitations.

Programming sprites

The basic operations on any sprite system:

Operation	Description
Position	Set X/Y coordinates in screen space
Pattern / pointer	Which graphic to display (index into tile / pattern memory)
Enable	Turn the sprite on or off
Priority	Draw order relative to background and other sprites
Flip	Horizontal / vertical mirroring (varies by platform)
Palette	Which colour set to draw with
Collision	Detect overlap with other sprites or the playfield

The exact register layout varies wildly between systems — see the linked hardware references for specifics.

Commodore 64

The Programmer’s Reference Guide sells the VIC-II’s sprites as a package: “tell a sprite ‘what to look like,’ ‘what color to be,’ and ‘where to appear.’ The VIC-II chip will do the rest!” Each of the eight is a 24×21 block of 63 bytes with its own colour, an optional multicolour mode, 2× magnification in either or both directions, and collision detection against other sprites ($D01E) and the background ($D01F). Priority between sprites is fixed — sprite 0 is always in front, sprite 7 always behind — and priority against the background is a per-sprite bit in $D01B. The guide’s pitch was that “because the sprites are maintained by hardware, it is even possible to write a good quality game in BASIC”, and it already points beyond eight: “More sprites can be displayed using RASTER INTERRUPT techniques.”

Hardware sprites vs software sprites

Type	Examples	Trade-off
Hardware sprites	C64, NES, MD, SNES, Amiga	Fast (zero CPU cost), but constrained by chip’s sprite limits
Software sprites	ZX Spectrum, IBM PC pre-VGA, Mac	Unlimited count, any size, but every sprite costs CPU time to render
Hybrid (BOBs + sprites)	Amiga, MSX	Hardware sprites for hero, software (BOB / blit) for everything else

The Spectrum’s lack of hardware sprites forced its developers into software tricks: pre-shifted sprite tables, OR-blit rather than replace-blit, attribute-only animation.

Per-scanline limits

Most sprite hardware can only display N sprites simultaneously on a given scanline. If more sprites cross that line, the lowest-priority ones disappear or “flicker” (alternate between visible and hidden frames):

Platform	Per-line limit	What happens above limit
C64	8	All visible (no per-line limit; sprites multiplex via raster IRQ tricks)
NES	8	Lowest-numbered 8 are drawn; rest disappear (or flicker if shuffled)
Master System	8	Same — flicker via shuffling
Game Boy	10	Same
Mega Drive	20	Same — much more comfortable budget
SNES	32	Same

Sprite multiplexing — using raster interrupts to reposition sprites mid-frame — works around per-line limits on machines like the C64. See Sprite Multiplexing.

Special features

Collision detection

Platform	Type
C64	Sprite-sprite (`$D01E`), sprite-background (`$D01F`) latching registers
NES	Sprite-0 hit (`$2002` bit 6) — single bit, used for raster effects
Mega Drive / SNES	Software collision typical; some hardware help

Sprite scaling and rotation

A late-generation feature; first standard on SNES Mode 7 (background only, not sprites natively) and arcade Super Scaler hardware (Sega Hang-On, Out Run, After Burner). See Sprite Scaling.

Sprite-zero hit

NES-specific: bit 6 of $2002 sets when sprite 0’s first non-transparent pixel collides with a non-transparent BG pixel. Used to trigger mid-frame split effects (status bar above gameplay area in Super Mario Bros. and many others).

Hardware-accelerated game objects