Techniques & Technology

Attribute-Aware Design

Designing for the ZX Spectrum's two-colours-per-cell rule

How Spectrum designers and programmers worked with — and sometimes weaponised — the platform's attribute system: two colours per 8×8 cell, an entire visual language built from how that constraint is honoured, avoided, or embraced.

sinclair-zx-spectrum graphicsdesignattribute-clashcolour 1982–present

Overview

The ZX Spectrum's video hardware uses a separate attribute memory region ($5800-$5AFF) where each 8×8 character cell holds a single byte controlling its colour: 3 bits INK (foreground), 3 bits PAPER (background), 1 bit BRIGHT, 1 bit FLASH. Two colours per cell, no more, no fewer. The pixel data at $4000-$57FF says which pixels are lit; the attribute byte says what colour they're rendered as.

This sounds restrictive — and it is — but the entire visual identity of the Spectrum platform emerges from how programmers responded to it. Attribute-aware design is the umbrella term for the body of techniques developed across the platform's lifetime to either honour the two-colour rule cleanly, work around it strategically, or embrace its consequences (the famous "attribute clash") as part of the aesthetic.

The clash and what it looks like

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

  • Naive sprite renderer (clash visible): when the sprite enters a cell, that cell's attribute is overwritten with the sprite's colour. The pixels behind the sprite take on the sprite's colour too. As the sprite moves, it drags a trail of recoloured background cells behind it — attribute clash.
  • Sprite uses background's INK (no clash): if the sprite's design uses the same INK colour as the background's PAPER, only the bitmap changes. The cell's attribute stays — no clash. The cost: the sprite is the same colour as everywhere else.
  • Background cells masked off (no clash): the renderer detects sprite-cell intersection and leaves attributes alone (paying the cost of the sprite being invisible against same-coloured backgrounds).

For arcade-style games with moving multi-colour sprites, naive renderers were common and clash was visible. Critics in the 1980s reviewed games partly on how badly clash showed; later writers re-examined clash as an aesthetic in its own right.

Five strategies for working with attributes

1. Monochrome rooms. Every cell in a given scene has the same INK and PAPER attribute. 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: every isometric room is a single ink colour on black PAPER, with the sprite's pixels rendered in that one colour. The visual cost is reduced 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; cell attributes change cleanly as the sprite moves cell-by-cell rather than smoothly. Atic Atac and Sabre Wulf both use cell-aligned movement and avoid clash by snapping. The cost is choppy motion; the gain is clean colour transitions.

3. Colour zones. Divide the screen into regions with consistent attribute schemes. Manic Miner's individual caverns use this: each room is painted in a few specific INK colours against a black PAPER, with sprites designed to match the room's palette. Sprites moving within a zone don't trigger clash; sprites crossing zones do.

4. Bitmap-only motion (no attribute change). The sprite renderer changes ONLY the bitmap bytes at $4000-$57FF, never the attribute bytes at $5800-$5AFF. The sprite "wears" whatever colour the background already had. Shadowkeep uses this approach: the hero's INK/PAPER stays whatever the underlying floor was (white floor + black ink). The cost: the sprite cannot have its own colour independent of the cell it's in.

5. Embrace the clash. Use it as the aesthetic. Skool Daze (1984) lets clash happen everywhere — the schoolboy's red sprite drags red attributes across the school's green floors, and the visual feels of-the-era. Way of the Exploding Fist (1985) does the same. The platform's distinctive look in many games is the clash, not its avoidance.

The BRIGHT bit's special role

The BRIGHT bit doubles the effective palette without spending more attribute bits: a cell can be PAPER 4 (green) regular, or PAPER 4 + BRIGHT (vivid green). The same colour at two luminances. Designers use this to differentiate sprites from background within the same colour family: a sprite drawn in BRIGHT 1 red on a PAPER 2 (regular red) background pops out, with both cells still using "red" but one being noticeably brighter.

BLACK has no luminance, so BRIGHT 0 BLACK and BRIGHT 1 BLACK are visually identical. This is exploited by some games to ensure that the BORDER and PAPER black aren't broken by the BRIGHT-bit setting of nearby cells.

The FLASH bit

The FLASH bit causes the cell's INK and PAPER to swap about twice a second in hardware. Useful for:

  • Warning indicators (red FLASH = hazard in many games)
  • Loading screens (drawing attention to specific text)
  • Spell effects, hit-flash (transient FLASH on the player when damaged)

Excessive FLASH is visually exhausting; designers learned to use it sparingly and for genuine emphasis.

How this affects gameplay code

For games that encode game rules in attribute bytes (the Atic Atac lineage, including Shadowkeep), the attribute byte is doing two things at once: visually presenting the cell to the player AND encoding what the cell means (wall, floor, door, treasure). A single LD A, (HL) reads both — the rendering and the rule are the same byte.

This is the platform's most beautiful design accident. The Spectrum's two-colour limitation, intended to save attribute memory, ended up making the attribute byte rich enough to be the game's data model.

See also