Tile-Based Graphics

Overview

Tile-based graphics compose screens from small, reusable graphic elements (typically 8×8 or 16×16 pixels). Instead of storing unique pixels for every screen location, games store a tile set and a map of which tile appears where. This drops memory by an order of magnitude and is the only practical way to render full-screen worlds on hardware with kilobytes of VRAM.

For the map structure, attribute layout, and collision handling see Tile Maps; this entry covers the underlying concept and platform support.

Memory efficiency

A 256×240 NES screen with one byte per pixel would need 61,440 bytes — far more than the PPU's 2 KB of nametable RAM. Tile-based rendering rewrites the budget:

Component	Size	Notes
Tile set (256 tiles, 2bpp)	4,096 bytes	Stored in CHR-ROM/RAM, 16 bytes per tile
Nametable (32×30 tile indices)	960 bytes	Plus 64 bytes of attribute data
Total	~5,120 bytes	About 8% of the equivalent bitmap

Tiles also compress further: a screen full of "sky" reuses one tile thousands of times across the map, costing one byte per cell.

Hardware support

Most tile-based systems combine a fixed-size tile cache (CHR/VRAM) with one or more nametable surfaces of tile indices:

System	Tile size	Tile cache	Notes
NES (PPU 2C02)	8×8	2 × 256-tile pattern tables (4 KB each)	$2000 bits 3-4 of PPUCTRL select which table is used for BG vs sprites
Mega Drive (VDP)	8×8	64 KB VRAM, ~1500 tiles after nametables/HSCROLL	Two scrollable BG planes + Window
Game Boy (PPU)	8×8	384 tiles in 8 KB VRAM	Two of three 256-tile windows overlap (signed indexing)
Master System (VDP)	8×8	448 tiles in 16 KB VRAM	Single nametable, 32×24 tiles
C64 character mode	8×8	256 chars (one charset) at any 2 KB-aligned address	Multicolour mode trades horizontal resolution for 4 colours per cell

The Mega Drive and Master System share the same Yamaha VDP lineage; both fetch tile pixels from VRAM through nametable indices.

Design implications

Tile constraints shaped game design throughout the 8/16-bit era:

• Modular level construction — designers built levels from a fixed alphabet of tiles, often grouped into "metatiles" (4 or 16 tiles forming a logical block).
• Reusable environment pieces — Super Mario Bros. fits its entire visible world in 256 unique 8×8 tiles by re-skinning the same shapes in different palettes.
• Editor-friendly — tile-grid maps fit naturally into 2D arrays, making level editors tractable on the host computers of the era.
• Cheap collision — the same map index that draws a tile can carry a collision class (solid / platform / hazard), so the physics test is one array lookup.

Modern relevance

Tile-based approaches persist:

• 2D indie games (Celeste, Stardew Valley, Hollow Knight)
• Mobile and web games where memory and bandwidth still matter
• Procedural generation, where authoring an alphabet of tiles is much cheaper than authoring full bitmaps
• Level editors as an end-user feature (Super Mario Maker, LittleBigPlanet)

See Also

• Tile Maps — map data, attributes, scrolling
• Character Graphics — C64 character mode in depth
• PPU — NES tile-rendering hardware
• Memory Mapping