Tile-Based Graphics

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.

On the Commodore 64

The C64’s tile set is its character set. The Programmer’s Reference Guide explains that the VIC-II normally fetches shapes from the character generator ROM, but can be pointed at “patterns located in RAM memory” instead: 256 characters of 8 bytes each, 2K in all, at any of eight 2K positions within the 16K the chip can see, selected by three bits of register 53272 ($D018). That is the whole mechanism — a screen is 1,000 bytes of indices into a 2K set of user-drawn shapes — and it is cheap enough that programmers used it for moving objects as well as backgrounds. Planning a Space Harrier conversion in 1986, Chris Butler told ZZAP! 64 he would be “using character graphics rather than sprites, and that should save a hell of a lot of memory”, and dismissed the speed worry: “you’re shifting around 2K of memory every fifty Hertz — even with decent sized character sprites, you’re not going to be touching 2K.” See Character Graphics for the C64 mode in depth.

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