All Points Not Addressable
When Colors Clash, Part 2
When the IBM PC was released in 1981, the Color/Graphics option had a still somewhat uncommon feature that IBM called “all points addressable graphics” in the documentation. What this meant was you could take any pixel on the screen, set it to any available color you wanted, there was no impact or limitation from the colors of adjacent pixels and you were not limited to only choosing characters from the character set as with text modes. Most color computers of the era weren't quite this flexible and still had some unusual color limitations; in order to keep costs down while improving performance, a myriad of color schemes were devised which provided more colors on the screen at one time than the IBM PC offered, but the tradeoff was you couldn't just set any pixel to any arbitrary color. One of the more common schemes was to limit colors to only two per block of pixels (such as on the ZX Spectrum which allowed two colors every 8x8 pixels). Color clash (sometimes also known as attribute clash) was the term commonly used for the resulting artifact of colors seemingly bleeding from one area into another that resulted with these color schemes. Creating graphics within these limitations was a challenge and previously I looked at a few examples in When Colors Clash. These were all loading screens from a handful of 8-bit computers in order to demonstrate the issue and show examples of how artists worked with the constraints for static screens. Getting attractive graphics put together was tough enough there, but what happens if we add movement to the equation? Usually trouble! For action games (or any game with some sort of animation) the problem is now worse as the artist has less control over where to position elements on the screen to hide or work around color clash, instead the graphics need to follow the action of the game. Some common patterns and techniques did emerge, however, so this time let's take a look at a few of the tricks of the trade developers utilized to deal with this limitation outside of the loading screen and during the game itself.
Dealing With Color Clash During Gameplay
Keep Graphics Confined to One Block
One of the earliest techniques was to make all of the objects on screen take up exactly one block of pixels and have movement (if any) remain fixed to that grid. On the ZX Spectrum, a system designed more for text than graphics and the poster child for color clash, this gave you you only 8x8 pixels to work with. Not a lot of detail was possible with that size, and some games had gameplay designed with this limitation in mind.
Black Crystal Black Crystal is mostly a text based game; but while parts of it are traditional text-only interactive fiction, other sections present as a top-down view of the world where everything fits perfectly into a grid made up of 8x8 pixels. This not only helps avoid color clash on the ZX Spectrum and the later Commodore 64 versions, but is necessary for the ZX81 release (The ZX81 didn't offer any graphic options, but did have a number of special characters that programmers could use to create crude graphical images). There's little animation, and when there is characters move by 8 pixels at a time.
| Black Crystal | |
| ZX Spectrum Version | |
 |
 |
Captain Fizz Meets the Blaster-Trons Even some later, more action oriented games could keep everything in nice 8x8 pixel blocks. Captain Fizz is an example where the game world fits neatly into this size allowing for a colorful screen with no color clash. The player's character, enemies, explosions, laser fire, walls, and so on are all the same size and again move by exactly 8 pixels at a time. The game uses a flip-screen so scrolling isn't a worry.
| Captain Fizz Meets the Blaster-Trons | |
| ZX Spectrum Version | |
 |
 |
Objects Fit In Multiple Blocks
Not just games where the gameplay was inherently grid-based used this trick. Some action games also achieved decent results by taking the previous concept and increasing the size of objects by using multiple blocks (e.g. by using 4 blocks you could have a 16x16 pixel object) and having animation that only moved 8 pixels at a time. Since everything still fits nicely on the grid, color clash doesn't occur. However, there are some drawbacks with this technique; for one animation isn't very smooth since movement is by an entire block at a time instead of by a single pixel which can lead to a more jumpy appearance. There also isn't much flexibility in size when creating the character graphics since moveable objects need to fit exactly into a multiple of the block size. Lastly, if your character wasn't perfectly blocky (usually the case) you would have some unused pixels around the edges which would be visible if the game had background graphics as square, black borders. Here's a few examples of this technique in action.
Darius+ Darius+, originally known simply as Darius in the arcades, also keeps everything neatly in 8x8 pixel blocks however it shows what you can do with larger objects and more detailed backgrounds. Almost all of the objects in the game take up multiple blocks while movement of the background, the player's ship, and enemies are still all by 8 pixels at a time so everything remains within the Spectrums color grid. In cases where a foreground object overlaps the background, color clash is avoided by not using transparency of any sort; you'll see a black, square border around the object.
| Darius+ | |
| ZX Spectrum Version | |
 |
 |
Golden Axe Like Darius+, Golden Axe has characters sized to take up multiple blocks. For this game the shape isn't always square or rectangular, and some characters are quite large which helps to make the trick less obvious. Once again note that where characters aren't perfectly square you'll see some empty black space in order to prevent the background from picking up the character's color (or vice versa).
| Golden Axe | |
| ZX Spectrum Version | |
 |
 |
While this worked well if it just so happened that the gameplay could fit well into the rigid grid system, it wasn't always flexible enough for games, especially if you wanted smoother animation and for those games ported from more powerful systems or the arcade where color limitations were not considered for the game design. So most of the time a different trick was desired...
Monochromatic Playfield
One of the easiest ways to avoid color clash is to simply not use color at all. Making the playfield or any area of the screen where animation occurs black and white (or some other single color instead of white) was a common technique. Borders around the screen, text and menus, status or scoring areas, and anywhere else where animation didn't exist could still use different colors so the entire screen wasn't necessarily a single color, but the thorny issue of how to deal with color clash in the graphics and/or animation intensive parts of the screen was avoided. The main drawback (besides the game being less colorful and less attractive) was that it could make gameplay more difficult for some games. Without different colors, objects didn't stand out as well against a detailed background making it easy to miss something important or it was more difficult to discern between different characters. Due to the popularity of the ZX Spectrum, this technique could even appear on systems where color clash wasn't an issue (or was less of an issue); it wasn't uncommon to see Amstrad CPC and MSX games use the same monochromatic graphics as the ZX Spectrum version even though it was possible to provide a better solution. Here are a few games showing the technique.
Hammerfist In the first example, Hammerfist, the playfield uses only black and white but note that you still have some colors in the scoring area at the top of the screen. Other games that follow vary the playfield color, but stick with the same pattern of a single playfield color and a handful of other colors may be used for scores and other text.
| Hammerfist | |
| ZX Spectrum Version | |
 |
 |
Joe Blade II Joe Blade II is an example of a monochromatic game that didn't go strictly with black and white. It not only used a different color, but changed colors depending on which screen the player was on. The monochromatic graphics were carried over to some other systems as well including the Commodore 16 and BBC Micro. The Amstrad CPC version improved upon the Spectrum version; while the background graphics are the same and still a single color, it colored the various foreground characters differently so they stood out and there is no visible color clash. This game also illustrates another rarely used feature of the Amstrad CPC; raster interrupts. If you click the Joe Blade II and take a look at the screenshots, you'll notice there are more than 4 colors in the CPC version which normally shouldn't be possible. This is achieved by changing the color palette at particular scanlines; so it's still only the normal 320 x 200 resolution mode, but which 4 colors are used can change for different areas of the screen.
| Joe Blade II | |
| ZX Spectrum Version | |
 |
 |
Athena Athena, a frustratingly difficult arcade game, also used different colors for the 8-bit home version ports. Instead of having colors change for each screen the player wanders into, it instead has the colors change for each level in the game.
| Athena | |
| ZX Spectrum Version | |
 |
 |
Partially Monochromatic Playfield
Similar to above, except some games expanded the concept to include more than one color in the playfield but overall kept color use to a bare minimum. Usually the colors would change along some sort of natural boundary line, such as having the sky one color and the ground another. Objects or characters would simply adopt the color of the area they happened to be overlapping. While perhaps a slight improvement over the completely monochromatic playfield, it overall had the same drawbacks; it could still be difficult to pick out objects and characters if they were against a detailed background.
Chase H.Q. The first game shown below is Chase H.Q. which uses cyan for the sky and yellow for the ground. In fact, you even have a simple gradient; the top of the sky is dark cyan with most of the sky being high intensity cyan. If you look closely, things don't always line up exactly; the horizon may move up or down a few pixels so from time to time the top of the ground may be cyan or the bottom of the sky may be yellow. Overall though the ground/sky divide makes for a nice way to add a little extra color while still using a mostly monochromatic color scheme to minimize color clash.
| Chase H.Q. | |
| ZX Spectrum Version | |
 |
 |
007: Licence to Kill The action game License to Kill overall uses yellow for the playfield, however like Chase H.Q. there are some naturual boundaries that can be different colors. This includes buildings, trees, and other areas in the playfield where the player and computer controlled opponents can't reach. For instance your helicopter can't fly through the buildings and combined with their square shape it's easy for them to take on another color without fear something will end up animated near or on top of it.
| 007: License to Kill | |
| ZX Spectrum Version | |
 |
 |
Background Color Priority
Now we're starting to add even more colors; instead of having the playfield be a solid color (or a very limited number of colors), the background now is in full color to the best allowed by the hardware. Characters and objects on the screen would consist of the same background color (usually black) with the second color adopted from whatever tiles happened to be overlapped at the time. This gave the illusion of objects being “transparent” as they didn't really have color of their own much of the time. The results tended to make for a much more attractive display, but clarity could still be an issue sometimes; since objects didn't have their own color there was nothing to make them stand out and you could sometimes find yourself wondering your character disappeared to.
Fantasy World Dizzy Codemasters' famous Dizzy series was originally created on the ZX Spectrum and exhibits this style for color. Our hero Dizzy is ordiniarily white, but whenever he walks past colorful parts of the scenery you'll see him take on those background colors in this version. The third entry in the series, Fantasy World Dizzy, provides us with some nice examples below.
| Fantasy World Dizzy | |
| ZX Spectrum Version | |
 |
 |
Mambo The Spanish action game Mambo uses this technique as well; shown below is the MSX version. Despite the more advanced capabilities of MSX computers, this game is ported from the ZX Spectrum version without any changes. Due the similar architecture comprised of a Z80 CPU and the same screen resolution of 256x192 in 15 colors, this was unfortunately common. The MSX had several major advantages that could have improved this game; instead of being limited to 2 colors per block of 8x8 pixels, the MSX could display 2 colors per block of 8x1 pixels (plus it was possible to mix high and low intensity colors in a block). Additionally, like the Commodore 64 it had hardware sprites which could have been used. The Amstrad CPC and IBM PC versions both use only 4 colors, but luckily don't copy the color clash. In the MSX screenshots below you'll notice the player's character and the enemy soldiers both take on the color of whatever background they are in front of.
| Mambo | |
| MSX Version | |
 |
 |
Object / Character Color Priority
This trick is the opposite of the previous one; here, any foreground objects and characters do have color and their color takes precedence over whatever they may be in front of (so where the object overlaps the background, the background will take on the color of the foreground object). Backgrounds could be monochromatic or have multiple colors also, but either way the foreground character's color was always kept so it would stand out but the result was a halo of the same color around it. Where there were detailed backgrounds this could make color clash particularly obvious. Also, if objects were animated smoothly and moved less than 8 pixels at a time, colors couldn't move as finely so you might see a smoothly animated character but with the colors jumping to follow it. If there were multiple foreground objects in close proximity, colors in these would even clash with each other.
Jungle Warrior Shown below is the MSX version of Jungle Warror; like Mambo above, it was ported from the ZX Spectrum version and exhibits the same color clash characteristics despite the hardware capabilities. In both of these shots you'll notice our hero is yellow, and wherever he walks any background graphics that happen to be nearby turn the same color.
| Jungle Warrior | |
| MSX Version | |
 |
 |
Casanova Another Spanish game, the ZX Spectrum version of Casanova employs this technique. In the shots shown here, notice that our damsel is green and any background near her similarly turns green. The same happens with our hero who is yellow, although in these particular screenshots it's not as noticable. Interestingly, the MSX and Amstrad CPC versions alter the formula; they follow the above trick of having our characters take on the background color.
| Casanova | |
| ZX Spectrum Version | |
 |
 |
No Backgrounds
Colors can't clash if they aren't near each other! Some games simply tried to avoid creating a scenario where color clash was a major problem by not having background graphics and not letting things get near each other if possible. When animated graphics are far apart, you could easily color them since there were no graphics in adjacent blocks. Color clash still existed and if two objects did get too close to each other you would see the colors change, but this was usually less obvious and distracting than some of the other scenarios where background graphics came into play.
Starquake Starquake is one of the games that keeps it's background clear and colors apart; color clash happens when the various enemies you encounter overlap (or even just get near each other, as seen in the second screenshot here), but overall it's a lot easier to have a colorful screen when you don't have pesky background to deal with.
| Starquake | |
| ZX Spectrum Version | |
 |
 |
Vixen Vixen is similarly sparse; with no background graphics and most of the time there aren't large numbers of moving characters on screen, colors can be kept apart keeping clashes to a minimum.
| Vixen | |
| ZX Spectrum Version | |
 |
 |
In both of these examples the platform graphics fit nicely into an 8x8 grid allowing them to be drawn and scrolled 8 pixels at a time without color clash, so it's mostly the open areas where the player and enemies are moved around by 1 pixel at a time that I'm looking at.
Black Borders and Shadows
Another way to keep colors away from each other was to surround objects with a large black border or shadow. This allowed objects and characters to fill up entire blocks which avoided the color clash, but it made that fact less obvious and gave a more natural appearance.
Dark Sceptre Use of this trick seems to be uncommon, and few games, if any, use this technique better than Dark Sceptre. With unusually large characters, the game uses smooth, 8 pixel thick borders around everyone on screen to impressively hide the color clash, even when characters walk past each other. This gives the ZX Spectrum version of the game an overall unique appearance compared with most others games not only on the Spectrum but other platforms as well; the only other version of Dark Sceptre is a port for the Amstrad CPC which uses the low res 16 color mode for the playfield. Due to the extra colors and lack of color clash, it doesn't have the same large borders for the characters and looks more or less typical for a CPC game.
| Dark Sceptre | |
| ZX Spectrum Version | |
 |
 |
007: Licence to Kill, shown above, also uses something similar to a more limited extent. Since the screen scrolls vertically, note that the trees, buildings and other objects which aren't yellow have an 8 pixel black bar above and below. This allows the screen to scroll and gives enough room around the non-yellow objects for color clash to not occur.
Parkour!
Sometimes there is so much color on screen a little color clash here and a little there almost gets lost in the chaos; rather than try to avoid it, just let it happen! You may not notice color clash as much when a screen is very busy and there's enough action that you don't have time to take a closer look at details. This technique has the advantage of a very colorful display making the game stand out from the numerous, less colorful games on the market, but whether or not that actually helps or hinders the game seems to vary depending on the given gameplay and graphics style.
Dan Dare III: The Escape Dan Dare III is an excellent example of this technique; color clash actually happens quite often, but due to all of the action on the screen it's not particularly noticable (so much happens so fast that the clash is often only visible for a few frames and with such vibrant graphics it's easy to miss).
| Dan Dare III: The Escape | |
| ZX Spectrum Version | |
 |
 |
Cybernoid: The Fighting Machine Cybernoid similarly has a lot of action on some of the screens. Since the screen doesn't scroll and the background where the player can navigate is black, color clash can be avoided in some areas, however when enemies begin appearing fast and furious (as often happens) color clash is frequent but far from the player's focus. Explosions can be particularly colorful as well!
| Cybernoid: The Fighting Machine | |
| ZX Spectrum Version | |
 |
 |
This trick can be tough to see sometimes with static screenshots just how much color chaos there is. To show it off a little better, here's what Dan Dare III looks like in action:
Sprites
Sprites are 2D bitmaps that can be composited against background graphics; many early computers and game consoles included specialized hardware specifically for handling sprites. This provided enormous benefit in the early days as the graphics could be quickly moved around the screen with even the slow CPU's of these systems and sometimes even collision detection could be handled in hardware. It also provided a partial solution to color clash; since the sprite data was stored seperately from the background bitmap data, when overlayed it appeared as if the rules for the number of colors per block were broken. The Commodore 64 and MSX computers that I've demonstrated in these articles both had hardware sprite capabilities as did the myriad of platforms also based on the TI TMS9918 display controller (ColecoVision, Memotech MTX, TI-99/4A, Sord M5, Tatung Einstein, etc), and more. I say above partial solution as the abilities sprites had could also be limited. It wasn't uncommon for there to be a limited number of colors allowed in a sprite (often just 1 color and transparent!) and the number of sprites allowed on a single scanline of the image could be limited. So you couldn't use them to simulate being able to fully set any pixel to any color you wanted, but it at least allowed clearer images by preventing some color clash. Assuming they were used, of course; many times the more advanced capabilities of some computers weren't always taken advantage of in ports. In some cases the sprite limitations themselves might have prevented their use; Freddy Hardest in South Manhattan can have numerous characters on the screen at once, but computers like the MSX only allow up to 4 sprites per scanline. Including the player and all of the enemies far more than that can appear on a single scanline so it seems use of sprites would not have been a complete solution to improve this version. Sometimes their lack of use came down to effort (or lack thereof) by the developers; porting games to various systems was often done quickly and re-coding the game and graphics to utilize sprites would have been additional cost some companies preferred to avoid. Hardware sprites weren't available on the ZX Spectrum so they couldn't help there, but here's a few examples on other systems where they not only improve performance but make the graphics clearer.
Fantasy World Dizzy The ports of the Dizzy series to the Commodore 64 take advantage of the platforms sprite capabilities. Let's take one more look at Fantasy World Dizzy; you'll notice in this version that our protagonist Dizzy retains his white color regardless of what background graphics or other characters are nearby.
| Fantasy World Dizzy | |
| Commodore 64 Version | |
 |
 |
Vixen Vixen also makes use of sprites on the Commodore 64. For large parts of the screen the game uses the hi-res 320x200 graphics mode which only allows 2 colors in an 8x8 pixel block. It may be tough to spot at first, but take a close look at our heroine and you'll see that she has more than 2 colors in a block which seemingly exceeds our limitation. This is achieved by overlaying more than one sprite on top of each other; it both gives us more colors for the character and allows animation without other characters or the background interfering with each other.
| Vixen | |
| Commodore 64 Version | |
 |
 |
Zoom In for The Details
If you've never seen color clash before, it may be difficult for some to spot the artifacts I've been rambling about in the various screenshots. So just in case, here's a few shots zoomed in to part of the image to make it easier to see. For comparison, the version on the left is the actual screenshot, while the version on the right is a Photoshopped version to show an alternate universe where color clash doesn't exist to highlight the colors that probably would have been different had the hardware actually allowed it.
| Casanova | |
| Actual Version | Hypothetical Version (color clash removed) |
 |
 |
| Jungle Warrior | |
| Actual Version | Hypothetical Version (color clash removed) |
 |
 |
Oddities
Last time I pointed out After the War as being somewhat weird for it's emulation of ZX Spectrum artifacts on IBM PC and compatibles with VGA graphics, this time around I'll point out Omega Dimension as being rather curious on the PC. This somewhat obscure spanish game only supports CGA and EGA graphics, but it appears the graphics for each mode were ported from a different version of the game. The EGA graphics rather closely recreate the ZX Spectrum graphics; this includes using a single color for the playfield and characters even though EGA had no limitations necessitating this. The CGA version, on the other hand, looks closer to the Amstrad CPC version; this version fortunately improved on the Spectrum version by having objects and characters use a different color than the background so they stand out. For the PC release, this quirky decision creates the unusual scenario where even though the EGA version uses more colors, the game is easier to play in CGA due to the way colors are used! While overall it's just another game with little effort put into the PC port, this odd difference between the CGA and EGA graphics is fairly unique.
| Omega Dimension | |
| EGA | CGA |
 |
 |
And That's a Color Wrap!
That's all for this time! These aren't the only technique used for color when color clash is a concern. Games did many different things to work within the constraints including using more than one trick I listed at the same time. However they did it, it certainly made things challenging! As 8-bit computers were replaced with more advanced 16-bit systems and beyond, color clash slowly became a thing of the past. Hopefully you enjoyed this brief journey back to the 80's when color was a headache to implement; until next time take care!