BBC Sprites

Overview

Because there is no hardware sprite system, a sprite is just pixel data the program places into the bitmap. There are two routes. The tidy route uses the OS: VDU and the OSWORD plotting calls read and write pixels through the current MODE, so the same code works in any graphics MODE. The fast route writes bytes directly into screen memory, which is far quicker but must match the exact pixel packing of the chosen MODE. All the cost is in the CPU, so sprite size and count trade against frame rate.

Sprite format

A directly drawn sprite is stored in the same packed form as the screen it goes into, so its bytes can be copied with little work. The screen is organised as 8-pixel-tall character cells laid out in columns of eight bytes, so a sprite is normally held as a grid of these cells, each cell being eight bytes top to bottom, and the cells running left to right. A sprite with a mask stores a second byte for every data byte.

Drawing to the screen

Through the OS, a sprite can be plotted by reading the current graphics point with OSWORD 10 to fetch a character definition or by issuing VDU commands that plot lines and points. For blocks of pixels, games more often copy their own byte tables straight into the display file. The address of a screen byte follows the MODE's memory layout: the display is a run of 8-byte character cells, so moving one cell to the right advances eight bytes and moving down one pixel row advances one byte, until a cell boundary is crossed and the address jumps a screen row.

To move a sprite the program first restores the pixels it covered, either by saving them before drawing or by redrawing the background, then draws the sprite at the new position. Because the byte layout is cell-based, a sprite whose left edge does not sit on a cell boundary must be shifted within the byte, split across two bytes in the same way as on other bitmap machines.

Masks and background

There is no hardware transparency, so masking is done in software. To place a sprite over a background without a solid box around it, each screen byte is combined with the sprite in two steps: AND with the mask to clear the pixels the sprite will occupy, then OR with the data to fill in the shape. The mask has clear bits where the sprite is opaque and set bits where the background should show through. In the multi-colour MODEs a pixel spans several bits of a byte, so the mask must clear whole pixel fields rather than single bits.

Both data and mask advance through the display using the cell-based address rules. Saving the covered background before each draw, then writing it back before the next, lets a sprite move over detailed scenery without leaving a trail.

Colour and modes

A sprite's appearance depends entirely on the MODE it is drawn in, because the number of bits per pixel and the packing differ. In a 2-colour MODE each byte is eight pixels and a sprite is compact but monochrome. In a 4-colour MODE each byte is four pixels, each two bits, and a sprite carries its own colours from a four-entry palette. In the 8-colour or 16-colour MODE each byte is two pixels. A sprite designed for one MODE cannot be poked into another without repacking, so games commit to a MODE and store sprites in that MODE's form. Colours themselves come from the logical-to-physical palette, so a sprite's colours can be remapped without touching its pixels.