Attribute-Aware Design

The ZX Spectrum’s video hardware keeps a separate attribute memory ($5800-$5AFF) in which each 8×8 character cell has one byte: 3 bits INK (foreground), 3 bits PAPER (background), 1 bit BRIGHT, 1 bit FLASH. The pixel data at $4000-$57FF says which pixels are lit; the attribute byte says what colour they are. The manual puts the consequence plainly: “you cannot possibly have more than two colours in a given block of 64 dots.”

Attribute-aware design is the umbrella term this vault uses for the body of techniques developed across the platform’s lifetime to honour the two-colour rule cleanly, work around it, or accept its consequences — the colour clash entry covers the artefact itself.

What the renderer decides

When a sprite moves across a coloured background, what happens depends on what the renderer does with attribute memory:

• Attribute rewritten (clash visible): when the sprite enters a cell, that cell’s attribute is overwritten with the sprite’s colour. The background pixels in the cell take the sprite’s colour too, and the sprite leaves a trail of recoloured cells. Any game that prints through the ROM gets this for free, because the ROM’s print routine always writes the attribute.
• Sprite uses the cell’s INK (no clash): the sprite’s pixels are drawn in whatever ink the cell already has. Only the bitmap changes. The cost: the sprite is the colour of wherever it is standing.
• Attribute left alone (no clash): the renderer never touches attribute memory during play. The scene’s colours are laid down once and the bitmap moves underneath them.

CRASH reviewed games partly on which of these they had chosen. From late 1984 its comments box carried a “Use of colour” line, and the same issue could praise Avalon because its playing area “avoids messy attribute problems” and note that Zombie Zombie’s new colour “has unfortunately introduced some attribute problems along with it”.

Five strategies

1. Monochrome rooms. Every cell in a scene has the same INK and PAPER. The sprite can move anywhere; clash is impossible because every cell already has the sprite’s colour scheme. Knight Lore (Ultimate, 1984) is the canonical example: each isometric room is a single ink on black, and the sprites are drawn in that ink. The cost is colour variety per scene; the gain is uncompromised motion and isometric occlusion.

2. Block alignment. Force all moving sprites to occupy whole 8×8 cells. The sprite snaps to the grid, and cell attributes change cleanly as it moves cell by cell. The cost is choppy motion, which is why arcade-style games rarely took it; the gain is that clash becomes impossible rather than avoided.

3. Colour zones. Put the colour where the sprites are not. Avalon keeps its “borders very colourful” and its playing area “quite simple”; Sabre Wulf takes the idea to its limit, with the entire playfield black and every colour pushed out into an impassable border. The player moves smoothly, mid-cell most of the time, and never meets a coloured cell to clash with.

4. Bitmap-only motion. The sprite renderer changes only the bitmap bytes at $4000-$57FF, never the attributes. The sprite wears whatever colour the cell already had. Sinclair BASIC has the same idea built in: INK 8 and PAPER 8 mean “transparent” — “the old attribute shows through” — so a BASIC program can print over a coloured scene without recolouring it. Shadowkeep uses this approach in machine code: the hero’s INK and PAPER stay whatever the floor was.

5. Masking. Give the sprite a black surround wide enough to blank the cells it is entering, so no cell ever holds both sprite and scenery. This is the only strategy that keeps both a coloured background and a freely moving sprite, and Your Sinclair spotted it on sight in a 1986 preview of Dark Sceptre: “Look at the size of that mask — no attribute problems here.” The cost moves to the scenery, which is punched out around the figure.

There is a sixth position, which is not a strategy: accept the clash and ship. Komplex’s “Use of colour: excellent once you accept the attribute problems” is the reviewer’s version of it, and Software Creations’ account of Ghouls ‘n’ Ghosts is the programmer’s — “The design of the backgrounds is severely limited by the scrolling technique, but the continuous smooth scrolling adds so much to the gameplay that this limitation can be endured.”

The BRIGHT bit

BRIGHT doubles the effective palette without spending more attribute bits: a cell can be PAPER 4 (green) or PAPER 4 with BRIGHT (vivid green). The same colour at two luminances, so a sprite in bright red on a normal red background still reads. Black has no luminance, so bright black and normal black are the same colour; that leaves fifteen distinct colours, not sixteen.

The FLASH bit

FLASH is “done by swapping the ink and paper colours” in hardware, with no work from the program: set the bit and the ULA alternates the two. Games use it for hazards, hit-flashes and “press a key” prompts; loading screens use it to draw the eye to a line of text.

The attribute as data

Because the attribute byte is one byte per cell, it is also a convenient map of the screen. Vectron (Insight for Firebird, 1986) stored its maze in the attribute file — “Using the attribute file to overlay a map of the maze was an inspired idea”, CRASH said — and Shadowkeep encodes what each cell means (wall, floor, door, treasure) in the same byte that colours it. A single LD A,(HL) reads both: the rendering and the rule are the same byte.

See also

• Sinclair ZX Spectrum
• ULA
• Colour clash — the artefact these strategies answer.
• Knight Lore — monochrome rooms.
• Sabre Wulf — colour in the border, black arena.
• Ghouls ‘n’ Ghosts — backgrounds designed around the scroll.
• UDG — programmer-supplied 8×8 character cells.