Skip to content

Tile-Based Graphics

Building worlds from small pieces

Tile hardware draws the screen from a set of small pictures, usually 8×8 pixels, and a grid saying which goes where. It let the NES show a 256×240 screen from 2K of video RAM, gave the Game Boy 384 tile patterns in 6K, and turned the Commodore 64's character set into a game's scenery, and sometimes its moving objects too.

A bitmap of one NES screen, 256 by 240 pixels at the console’s two bits per pixel, would take 15,360 bytes. The NES has 2K of video RAM. Its picture chip, the PPU, gets round that by never storing the picture at all. It keeps a set of small square images, 8 pixels by 8, and a grid of numbers saying which image goes in each square of the screen. As the beam sweeps across the television, the chip reads the number for the square it is about to draw, fetches that image’s pixels and paints them. One screen’s grid and its colour data need 1,024 bytes.

That is tile-based graphics: a picture assembled on the fly from a shared stock of pieces. Many 8-bit and 16-bit consoles worked this way, and so did the text modes of home computers. The price is that everything on screen has to be made from the pieces. A level designer has a fixed alphabet of shapes, a wall that looks different in every square costs a tile per square, and anything that must move smoothly across the grid needs either sprites or a lot of work from the processor.

This entry covers the display side: what the hardware does and which machines had it. How games laid out and compressed the grid itself is in Tile Maps.

How the machines did it

Machine Tile Where the patterns live How many
NES (PPU 2C02) 8×8, 2 bits per pixel, 16 bytes Two 4K pattern tables on the cartridge 256 per table; bits 3 and 4 of PPUCTRL ($2000) choose which table the sprites and the background use
Game Boy 8×8, 4 shades of grey 6,144 bytes of character RAM, $8000–$97FF 384: 128 for sprites only, 128 for the background only, 128 shared; the LCDC register picks which two blocks the background uses
Commodore 64 (VIC-II text modes) 8×8, 8 bytes A 2K character set in RAM, or the character ROM 256 per set, at one of eight 2K positions in the 16K the VIC-II can see
Mega Drive (VDP 315-5313) 8×8 “cell”, 4 bits per pixel, 32 bytes 64K of video RAM, shared with the plane, sprite and scroll tables An 11-bit pattern number in each map entry, so up to 2,048 patterns, fewer once the tables take their space

The details shaped the games. On the Game Boy, the 128 shared characters are what let sprites and background use the same images. The C64’s character ROM turns up as a ghost in two of the VIC-II’s four 16K banks: in bank 0 and bank 2, Commodore’s guide explains, the chip sees the ROM at $1000 and $9000 “even though the character ROM is actually at location 53248-57343 ($D000-$DFFF)”, so a program that wants its own character sets there has to move the VIC-II to another bank. The Mega Drive’s VDP gives each grid cell a 16-bit entry, and the bits beyond the pattern number pick a palette and mirror the tile, so one stored image can face both ways. The same chip keeps a second display mode, Mode IV, which Sega’s manual describes as being “for compatibility with the MASTER SYSTEM”.

On the Commodore 64: characters as tiles

The C64 has no tile hardware under that name. Its tile set is its character set. The Commodore 64 Programmer’s Reference Guide explains that the VIC-II normally takes its shapes from the character generator ROM, but can use “patterns located in RAM memory” instead, “created by you”, which means “you can have an almost infinite set of symbols for games, business applications, etc.” A set is 256 characters of 8 bytes, “256*8=2K bytes of memory”, and three bits of register 53272 ($D018) choose where it lies. The screen is then 1,000 bytes of character codes, 40 by 25, each pointing into those 2K of shapes.

Programmers used characters for more than scenery. Chris Butler, planning the C64 conversion of Space Harrier in 1986, told ZZAP!64 that filling “at least 64K with graphics” would leave no memory, so he would be “using character graphics rather than sprites”. The interviewer asked whether that would slow the game down. Butler’s answer was arithmetic: the machine could already move “around 2K of memory every fifty Hertz”, and “even with decent sized character sprites, you’re not going to be touching 2K”. Character Graphics covers the C64 modes in more depth.

Making a little go a long way

With a fixed stock of pieces, reuse is the whole craft. Super Mario Bros. had 8K for every tile of scenery and every frame of every sprite. Shigeru Miyamoto told Satoru Iwata in 2010 that he managed the budget on the planning sheet, “making the greenery and clouds out of the same parts”: the bushes on the ground and the clouds in the sky are the same tiles in different palettes.

The same grid that draws the world can describe it. A tile’s number can carry a class as well as a picture, solid, ledge, ladder or hazard, so the program can find out what is under a character’s feet with one table lookup instead of testing pixels. Tile Collision shows how.

Sources

  • Nintendo, Game Boy Programming Manual, version 1.1, chapter 2, “Display Functions”, p. 50: 8×8 characters; 128 OBJ-only, 128 BG-only and 128 shared characters; character RAM of 6,144 bytes from 8000h to 97FFh; LCDC selecting 8000h–8FFFh or 8800h–97FFh for the background.
  • Sega, Genesis Software Manual (1992 revision): the hardware overview at the front (4 bits per pixel, “32 bytes for complete char definition”, two bytes per playfield position with flip and palette bits); pp. 5–6 (VDP 315-5313, Modes IV and V, Mode IV “for compatibility with the MASTER SYSTEM”, the 8×8 cell, 64K bytes of VRAM); p. 42 (the 11-bit pattern number).
  • Commodore 64 Programmer’s Reference Guide (Commodore Business Machines), pp. 102–104: character memory, the character generator ROM, “patterns located in RAM memory”, “256*8=2K bytes”, eight possible locations, register 53272, the ROM image at $1000 and $9000 in banks 0 and 2.
  • NESdev Wiki, “PPU pattern tables”, “PPU registers” and “PPU nametables” (community reference, web, secondary): two 4K pattern tables of 256 tiles, 16 bytes per tile; PPUCTRL bit 3 (sprite pattern table) and bit 4 (background pattern table); the 960-byte nametable and 64-byte attribute table. https://www.nesdev.org/wiki/PPU_pattern_tables
  • “The Butler Did It”, Gary Penn talks to Chris Butler, ZZAP!64 issue 17, September 1986, p. 104: the Space Harrier plan, character graphics rather than sprites, 2K “every fifty Hertz”.
  • Nintendo, Iwata Asks: Super Mario Bros. 25th Anniversary, Volume 5, “Original Super Mario Developers” (2010, web), page 4: Miyamoto, “making the greenery and clouds out of the same parts”. https://iwataasks.nintendo.com/interviews/wii/mario25th/4/2/

See also

Checked. Verified against primary sources and signed off by a person.