Graphics in Early Arcade Games: Tilemaps

Tiles from the arcade game, Phoenix (1980).

Recall, in my entry on vector graphics, the logistical problem posed by Space Invaders.  The graphical demands of video games had increased to the point that, even with cutting edge microprocessors, games weren't able to keep up with the display updates.  Vector graphics offered one possible solution, but most video games didn't take that approach.  Instead, they used tilemaps.

Origin of Tilemaps

It may have taken until the early '80s for tilemaps to become standard in video games, but the idea had actually been around for quite a while before that.  It originally comes from text-only devices, where the only graphics that are needed are those defined in a character set.  

For example, suppose I want to display characters in 8-pixel by 8-pixel squares on a black-and-white display.  Each pixel is 1 bit of information (black or white), so each tile is 64 bits, or 8 bytes.  If the CPU needs to determine the color of every pixel in the display individually, then it will need to process all 8 bytes of information every time it displays a character.

Animation showing the phrase "Tiling is easy on the CPU" being constructed from tiles.

If, on the other hand, we store the graphics for the character set ahead of time in ROM (or load it into RAM at machine startup), then from the standpoint of the CPU, displaying a character is just a matter of selecting a tile.  If we're using, for example, UTF-8, then this is only 8 bits of information per character.  This corresponds to a load on the CPU that's 8 times lighter than with pixel-by-pixel processing.

Tilemapping Applied to Video Games

Graphics in video games are much more complex than in a text-only terminal, but the tilemap concept is essentially the same.  For example, look at the set of tiles below:

Image showing the tiles available in the Pac-Man arcade game (1980).  It uses the red-white-blue color scheme.

You probably recognize this as a Pac-Man tile set.  We still have letters and numbers in there so that the game can do things like tally your score and display messages on the screen.  However, there's a lot more here.  

For one thing, there are the pellets in the top row, which appear to be the only game objects that can be squeezed into 8x8 tiles.  Just as letters and numbers are the fundamental components of a paragraph of text, pellets are a fundamental component of the maze in Pac-Man.  So maybe we can think of them as part of an extended character set.

But the other tiles are clearly not meaningful on their own.  Rather, the game can use them as building blocks to craft the larger image.  For example, we can use the blue-and-beige tileset to construct a portion of the maze:

Animation of the construction of a portion of the maze in Pac-Man, using tiles from the in-game tile set.

In constructing a tilemap, the CPU decides which tiles go where based on the instructions in ROM.  Then the tilemap is stored in video RAM, which is used by the graphics processing unit to display the image.

Color Schemes in Tilesets

Notice that while the two tilesets shown in the previous section represent the same set of objects, they each use different color schemes.  The designers could, theoretically, have stored all of the tiles with a single color scheme (Q-Bert did this), but most games used only a small fraction of the full color palette in a given set of tiles.  Pac-Man, for example, made use of a palette of 16 different colors, but any given set of tiles would only use up to four at a time.

Animation showing six different color schemes in the Pac-Man tileset.

Consider what this means for the amount of memory needed to store a tile.  If every 8x8 tile is made up of pixels that can be one of 16 different colors, that's four bits to represent each pixel, and you need 4 x 8 x 8 = 256 bits to store every tile.  If, on the other hand, I only use four colors in a tile, it's 2 bits of information per pixel and therefore, 2 x 8 x 8 = 128 bits per tile.  

Obviously, a four-color scheme requires less memory to store, but don't I then have only four colors available to me?  In a given color scheme, yes, but we can define multiple color schemes if we want to represent more colors in the game.  Since the color scheme is set on a per-tile basis rather than a per-pixel basis, the additional memory requirements to do this are modest.  

Pac-Man allows for up to 128 color schemes (it doesn't use them all, but memory is available for them), which is only 7 additional bits of information per tileThis means that a single 4-color tile requires only 2 x 8 x 8 + 7 = 135 bits of data.  This is barely more than half of the 256 bits needed for a 16-color tile.  And from the graphic design standpoint, you probably don't want to use more than a small fraction of your palette in a single 8x8 tile, especially on an '80s CRT display, lest you end up with a blurry mess of contrasting colors.

The use of color schemes is just another way that early video games tried to make the most of limited resources.  Different enemies could be created by just applying a different color scheme to the same sprite, like the ghosts in Pac-Man or the aliens in Galaxian.  Other games, like Centipede (1981), will use the color schemes to indicate different levels.

Animation with Tiles

The game best known for establishing the tiling model in arcades is Galaxian.  It wasn't the first arcade game to do it (Circus used tiles to generate its background, for example), but the Namco Galaxian hardware ended up being the basis for many, many subsequent arcade games.  Let's look at what Galaxian did to create its armada of aliens.

The tileset below includes fragments of the galaxians in three different states of animation.  The CPU constructs a tilemap in each frame, so a given alien can be animated by simply alternating the tiles that it uses in each frame.

Animation of the construction of the alien armada in Galaxian (1979) using a set of tiles.

Tiles are typically stored in RAM, allowing for very quick access, meaning that 60 fps animation was no problem even with a large number of aliens on the screen.  There are also tiles with a range of spatial offsets in x and y to allow the alien armada to gracefully move up-and-down, left-and-right.

Tilemaps vs. Sprites

Sprites and tilemaps are similar in that they're just bitmaps used to render objects on the screen.  However, whereas tilemaps are usually constructed by the CPU in real time and stored in video RAM, sprites are permanently stored in ROM.  As such, sprites were typically bigger than individual tiles and objects would be separately rendered in various states of rotation and/or animation.  Also, tilemaps were usually laid out over the entire screen, while sprites were overlaid on the tilemap and occupied only a small portion of it in any given frame.

The way tilemaps and sprites were used varied from game-to-game.  While it was pretty standard to render backgrounds with tilemaps, the choice of tilemaps or sprites for interactive game elements -- like the player and enemies -- varied from one game to the next.  In Pac-Man, the maze was laid out in a tilemap, but all of the characters were sprites.  Galaxian used a hybrid model where the aliens were rendered from a tilemap while they were moving in formation, but were converted to sprites when they began their descent.  Finally, Phoenix (1980), which has gameplay very similar to Galaxian, rendered everything with two different tilemaps, one on top of the other.  

The latter game, Phoenix, was quite an ambitious graphical endeavor for its time, and was part of the  motivation for this look back at the history of graphics in arcade games.  We'll look at it in more detail in a coming entry.


  1. "However, whereas tilemaps are constructed by the CPU in real time and stored in video RAM, sprites are permanently stored in ROM."

    I'm a little confused by that. I *think* what you're saying is that tilemaps are constructed from tiles stored in ROM (e.g. no image of Pac-Man's maze can be found in the ROM) while sprites are stored completely in ROM. But we can see that Pac-Man, the fruit, and the monsters are also constructed from tiles.

    My understanding is that the key difference is tilemaps are fixed to a rigidly-defined grid on the playfield. If one thinks of the screen as a chess board, each and every one of the tiles on the board may display any bitmap on it, but these bitmaps cannot move around on the screen as sprites do. Smooth-scrolling presented some challenges and had a number of different solutions. The advantage is that drawing tiles is cheap - drawing the entire screen's tilemap 60 is essentially a free action that the circuitry performs every frame, and changing the bitmap on any given tile is inexpensive, though expensive enough that most systems couldn't refresh the entire tilemap every frame.

    Sprites on the other hand can be drawn at any X,Y pixel coordinate on the screen, and sometimes come with neat functions like pixel-accurate collision detection, stretching, duplication, rotation, etc. But they're expensive and also come with hard per-scanline limits.

    Interesting that Galaxian uses tilemaps for the invaders when they're in formation, with baked-in offset tiles so that they can create the appearance of moving sprites. Never knew that - seems really hackish, but it works!

    1. So yes, every bitmap must eventually come from ROM at some point (unless it's actually encoded in the circuitry, as in space race). The instances you see of Pac-Man and the ghosts in the tileset are being used for the player's life count and the introductory splash screen, respectively. There may be other animations that use them, but I've never seen them used during gameplay. Everywhere else they're being generated from sprites. If you're using MAME, you can see what's stored in the graphics RAM (the tilemap) at any point in the game by pressing F4, then enter twice. If you do this during gameplay, you won't see Pac-Man or the ghosts show up in the maze (I never have, anyway).

      What you're saying about tiles being on a rigidly defined grid, I think that's mostly true, but I didn't want to make too general a statement about it because I know that the zeropoint of the grid can be shifted for scrolling and I wasn't sure if there were other cases where the hardware could perform shifts in the grid for the purposes of animation. In the Galaxian case, they implement smooth motion by preparing a large number of tiles with different offsets relative to the tile center, and then choosing the appropriate tiles depending on the armada's position.

      As for the hybrid tile/sprite approach, see Scramble for another example. There, the enemy ships are being drawn from tiles when they're on the ground, but changing to sprites when they launch. Note that Galaga abandoned the hybrid approach, and ended up using sprites for aliens both in formation and out of it.

    2. Didn't know about the F4 trick in MAME! I checked out a few games with this, interesting stuff. Regarding the tilesets, in Pac-Man, if you press F4, then enter once, and then '],' you'll see the tiles used for sprites. You'll know it's for sprites and not tilemaps because there will be multiple frames for animations.

      Some takeaways here - big Pac-Man, as seen in the cut-scenes is made up of multiple sprites. Monsters' eyes, left behind when you eat their bodies, are a palette swapped normal sprite. Monsters get sprites facing all four directions, while Pac-Man only gets two for facing right and down, and sprite-flipping achieves the other two directions. There is a single-frame explosion sprite which AFAIK is unused.

    3. I'll probably discuss more about the F4 viewer in my next sprite extraction entry, but I think you've figured out the main points about how to use it. It's incredibly useful for understanding how games manage their graphics. It doesn't always work -- the Williams' classics, for example, don't show anything in that view, either because the graphics are encrypted or because they're stored in a non-standard way that MAME doesn't recognize.


Post a Comment