Data Compression

Overview

Data compression makes data smaller for storage, then restores it when needed. For game developers working with kilobytes of ROM, compression wasn’t optional—it was essential. Level data, graphics, and music all benefited from compression. The techniques ranged from simple run-length encoding to sophisticated algorithms that squeezed every possible byte.

Fast Facts

Aspect	Detail
Purpose	Fit more data in limited space
Trade-off	Storage space vs decompression time
Common targets	Graphics, level data, text
Modern relevance	Download sizes, load times

Why Compression Mattered

Storage constraints by platform:

Platform	Typical ROM	Context
NES	32-512KB	Entire game
SNES	1-4MB	Larger but still constrained
C64	170KB	Single floppy disk
Amiga	880KB	OCS-era disk

Every byte saved meant more content.

Common Algorithms

Run-Length Encoding (RLE)

Replace repeated values with count + value:

Original	Compressed
AAAAAABBCCC	6A2B3C

Simple, fast, works well for graphics with solid areas.

LZ-Family (Lempel-Ziv)

Reference earlier data instead of repeating it:

Variant	Used In
LZSS	Many console games
LZ77	Later systems
LZ4	Modern games

Look for patterns that appeared before, store reference to earlier occurrence.

Huffman Coding

Assign shorter codes to common values:

Value	Frequency	Code
A	50%	0
B	25%	10
C	25%	11

Common data gets fewer bits.

Platform-Specific Techniques

NES

Technique	Use
CHR-ROM compression	Tile graphics
RLE levels	Repeated tile patterns
Metatiles	2x2 tiles as single unit

SNES

Technique	Use
LZSS variants	Most data
Mode 7 compression	Background maps
Custom schemes	Game-specific needs

Mega Drive/Genesis

Technique	Use
Kosinski	Sonic series graphics
Nemesis	Tile compression
Enigma	Tile mappings

Sega developed multiple proprietary schemes.

Compression Targets

Data Type	Approach
Tile graphics	Pattern-based, RLE
Level maps	RLE, dictionary
Music data	Pattern references
Text	Huffman, dictionary
Sprites	Custom per-game

Trade-offs

Factor	Consideration
Compression ratio	How much smaller?
Decompression speed	Can it run in real-time?
RAM requirement	Buffer size for decompression
Code complexity	Decompressor size

Real-time decompression (streaming audio/video) needed fast algorithms. Static data (level loading) could use slower, better compression.

Implementation Considerations

Challenge	Solution
RAM limits	Decompress to VRAM directly
CPU budget	Decompress during loading
Random access	Store block offsets
DMA conflicts	Time decompression carefully

Notable Examples

Game	Technique	Achievement
Sonic the Hedgehog	Multiple schemes	Large levels, fast loading
Super Metroid	LZSS variant	Massive map in 3MB
Kirby’s Adventure	Heavy compression	6MB of content in 768KB

The Demo Scene Connection

Demo scene coders pushed compression limits:

Compo	Constraint
64K intro	Entire demo in 64KB
4K intro	Extreme compression

Techniques developed for demos influenced game development.

Modern Relevance

Context	Application
Download sizes	Game distribution
Load times	SSD streaming
Texture compression	GPU formats (BC, ASTC)
Asset bundles	Runtime decompression

The principles remain even as storage grows—users still prefer smaller downloads.

Legacy

Compression taught developers to think carefully about data representation. The habit of asking “can this be smaller?” persists. Modern game developers still compress assets, optimise network packets, and minimise memory footprints. The stakes are different, but the discipline of fitting content into constraints remains valuable.

See Also

• Bank Switching
• Tile Graphics
• Demo Scene