This is a sidebar page

It provides more detailed information but you don’t need to read it to follow the tutorial. You might want to come back to it later.

The tilemap represents the screen-filling background of the graphics on the Master System. It is slightly larger than the screen, allowing the viewpoint to smoothly scroll while any updates to the tilemap happen in the off-screen parts.

Consider the “virtual screen”, which is 256×224 pixels. This is built up from a grid of 32×28 8×8 tiles. Each entry in this 32×28 grid is defined by an entry in the tilemap, sometimes called the name table. Each entry determines:

  • Which tile to display
  • Which palette to use
  • Flags
    • to make the tile to be drawn flipped horizontally (like a mirror image)
    • to make the tile to be drawn flipped vertically (like a reflection in a mirrored floor)
    • to make the tile to be drawn in front of sprites

Data format

The data takes up a total of 13 bits, stored in two bytes:

Bit1514131211109876543210
DataUnusedPriorityPaletteVertical flipHorizontal flipTile number

The data is stored in VRAM in little-endian format, i.e. the last eight bits are stored first.

The tilemap is usually stored in VRAM at location $3800, and takes up 1792 bytes (32×28×2 bytes).

Flags

Flipping

Flipping allows symmetric objects to be created with fewer tiles, thereby allowing greater variety in the graphics. In the above example, some tiles were flipped horizontally, shown by red arrows on the upper portion.

Priority

When a tile has its priority bit set, all pixels with index greater than 0 will be drawn on top of sprites. You must therefore choose a single colour in palette position 0 to be the background colour for such tiles, and they will have a “blank” background. Careful use of tile priority can make the graphics seem more multi-layered.

Notice how the monitor sprite is hidden behind the tree, and Sonic is hidden by the grass. The foreground tiles are highlighted by a drop shadow for explanatory purposes.

Not enough tiles to fill the tilemap

It would take nearly 900 tiles to fill the whole tilemap. It would take at least 744 to fill the smallest possible screen (on the Master System). There is only room in VRAM for roughly 450 tiles. Therefore, graphics have to be built up from tiles using some repetition of the same tile in more than one location in the tilemap.

This lack of a “bitmapped” display means you can’t do some types of graphics, and others are very difficult to achieve. It is therefore best to design your graphics around this limitation - drawing lines and unaligned text are very hard, but block-based graphics are very easy.

Automatic conversion

BMP2Tile will generate the tilemap data to match the input image, although it is up to you to handle cases where the image is not the same size as the tilemap itself. By using tile flipping, it can also reduce the number of tiles needed.

Game Gear differences

There (almost) aren’t any.

The “virtual screen” is the same size, but the displayed portion is of course the smaller 160×144 GG screen rather than the (typically) 248×192 SMS screen. That means that there are enough tiles to fill the entire screen and make a pseudo-bitmapped display (using 360 tiles, leaving plenty for sprites). It’s still hard work to work with this mode, though, as the data is not laid out in a regular “bitmapped” fashion, but fullscreen graphics are achievable.


< Tiles | Lesson 1 | Stopping >