Something incredibly charming yet at times annoying which occurred in some (most?) ZX Spectrum games, that the avid speccy gamer would notice (like an itch), but usually accept with no qualms or complaints, was Attribute Clash. Although this would now be looked on as a major glitch and totally unacceptable; this was something that Spectrum gamers found familiar and comfortable. It was not the end of the world if colours were clashing all over the place on a newly purchased game. It would not be returned to the shop and no refunds would be asked for. No patches to download or recalls from the publisher. It was not broken, it was just a Spectrum game.
Imagine the scene; your red and black character is walking across the screen in the foreground, and fast approaching is an amount of long green grass in the background. Nothing much would happen if a sprite
was to walk by some background imagery of grass, surely. Of course it wouldn’t, it’s not like the grass is poisonous (not in this game anyway), it’s not an enemy sprite, or some blazing fire or spikes. The grass is not deadly, it is just grass and it’s not going to affect the character in any way! So the character walks along and the grass is passing by in the background, and .. what on earth has happened?! The usually red character is, strangely, now green! What’s going on? Am I losing energy? Am I gaining points? None of the above. There’s nothing to see here, move along! Your character jump’s to a platform, and it’s correct colour has now returned as soon as it has left the grass. This is the infamous “attribute clash” in action. Although it seemed like the game was trying to communicate that something was happening to the grass or the character, it was nothing more than a graphic response due to the limitations of the good old Speccy. An unavoidable glitch.
Ok get ready for some numbers and stats (and this is without delving in to the intricacies of it all). Displaying the ZX Spectrum’s colour palette of 15 colours (a set of 7 bright colours, a set of 7 Dim colours, plus 1 colour of black which was present in both sets, making 15 colour’s total) was dependent on 32 rows and 24 columns, of 8 x 8 pixel boxes, known as Attribute Blocks. This invisible grid presented a problem to game artists and coders alike – as each menacing square only allowed 2 colours to be displayed in each (1 foreground colour known as “INK” and 1 background colour known as “PAPER”). To add to this problem; only colours from the same set (either bright, or dim) were allowed to be together in each block. Since both sets included black; both bright blocks and dim blocks could have black as one of it’s colours. Are you following?
If a third colour was introduced in to an attribute block, e.g. if a 2 colour character had walked in to something else or stood in the foreground of a different coloured wall in the background; then attribute clash (more commonly known as “colour clash”) would occur. The Spectrum would take the 3 colours inside that block and change the whole block back to 2. To add even more problems; even if only a single pixel of a third colour touched the attribute block of two other colours, then it was the whole attribute block that would change colour. That’s a whole 8 x 8 (64) pixel region of a sprite or background colour changing just because it stood a little bit too close to something on the screen that was a different colour. Still following? Sounds very messy doesn’t it.
So, what did it look like? Careful game design could counter it or disguise it, but there were a lot of subtle examples of attribute clash in a lot of games. Perhaps as a sprite walked in front of some red bricks it’s head (8 x 8 pixel regions of it) would change to red, which would even continue being red for a few frames of bypassing the bricks, as the sprite’s head’s attribute block still intersected it’s neighbouring red brick’s attribute block. Maybe a bird sprite happened to swoop down at our pixel protagonist and he collided with its wing, then 8×8 pixels of the birds wing would change colour as long as they were colliding. Subtle clashes were fine here and there, as mentioned in the opening paragraph it was completely acceptable and just another day for a Spectrum owner. The major travesty and something completely unacceptable to the player not only morally (“I parted with my money and it looks like *this*??”) but also physically to their eyes; was the absolute disregard for attribute blocks and their rules, which resulted in shocking displays of colour clash in certain games.
This made games look messy and harsh on the eyes, and really brought down the playing experience. There were a number of titles through the years that within the first few seconds of viewing the screen I had refused to continue playing, because of the nausea they caused. In later years with the arrival of computers such as the Amiga, and the dawning of an era of new games consoles with their vast colour palettes and no more colour clash issues, it really was a struggle for Spectrum programmers and designers to come up with ways to display credible incarnations of, for example, arcade conversions without colour clashing when 16bit machines were matching the visuals of their arcade big brother’s almost perfectly. Spectrum owners knew there were better versions of their games out there. They were not greedy; they took what they were given and accepted the limitations of their little rubber keyed friend when playing their games. They were (mostly) forgiving, and they accepted the following problems: “This is not the best game in the world… this is just Attribute(…clash).”
