a a a


Vol.32 No.2 May 1998

Graphics on the Wayback Machine

Maurice Molyneaux

Given the power of contemporary personal computers and set-top video gaming boxes, it may seem absurd to think that anyone would want to go backwards and deal with the limitations of the last generation of technology...and madness to go back two steps, or even three. Yet, there are people doing just that. Gaming enthusiasts continue putting pixel to bitmap on systems with such archaic names as Atari VCS, Vectrex and Colecovision.

I am one of them.

Kevin Horton is another of this group. He's the kind of electronics wiz who can look at a circuit board and simultaneously recognize all of its components and criticize their inclusion. A few years ago he was determined to make a game for the 1982 vintage Colecovision system. Unable to find development materials, he pursued what few leads he could find on the Internet, disassembled commercial Colecovision games and reverse-engineered the hardware. The result of this was that he produced a limited run of a new Colecovision game cartridge: a Tetris clone called KevTris, which he sold to the "classic game" collecting market. I met him some months after KevTris was completed, and was immediately hooked on the idea of helping him produce another game. He would engineer and code it; I would design the graphics and devise the gameplay.

Figure 1: Working screen of The Mating Game.

Kevin planned our game for a cartridge with a capacity of 256K, many times the size of a conventional Colecovision game. Originally he planned to fill this memory with a big "quest" type game and a few smaller bonus games. As things turned out, the quest game was eventually abandoned, and the best of the "bonus" games became our focus (the game is still in development as this article goes to press).

Part of the appeal of developing products for old systems is an exercise in nostalgia: bringing new life to a platform from our youth. Another part is vanity: seeing how much better we can do than the developers of the platform’s heyday. Finally, there's the very challenge of making something good with such crude tools.

I've always been intrigued by seeing just how far one can push the graphics of antiquated hardware. As far back as the late 1980s, I was using my 16-bit Atari ST computer to create graphics for older 8-bit home computers such as the Apple II, Atari 800 and Commodore 64. Since that time I've come to realize that many ancient systems are more graphically capable than one would guess by looking at the software produced for them. In most cases, it was as if no one ever really pushed the machines to their limits, perhaps because most of them had relatively short production lives, and their software never matured.

Figure 2: Colecovision game graphics.

The Colecovision (CV from here out) is a good example of this. The best graphics seen on the machine aren't very good. It's easy to blame this on the hardware. The CV's graphics were fairly powerful for its time, but in other regards, it is weaker than even the Atari VCS, which preceded it by five years. For instance, the Atari had a total palette of 128 colors to chose from; the number of which could be displayed on the screen at one time dependent on how clever the programmer was. In contrast, the CV is capable of displaying 15 colors on screen at one time out of a palette of...15 (there is a 16th: transparent, which is used for some background trickery, but really isn't a drawing color). The colors themselves aren't wonderful, mostly primary and secondary colors in a few different intensities, all fairly bright.

Additionally, the CV doesn't have a true graphical bitmap mode. While this is typical of game consoles from the dawn of the era through the Sega Genesis and Super Nintendo, it does limit one's options. Instead of a bitmap, screens are entirely "character based." Each CV screen consists of 32x24 characters, each of which is an 8x8 pixel grid. These characters can either be alpha-numerics or contain bit patterns to make graphical elements. Within each character any of the system's colors can be used, the restriction being that only two colors are permissible on each horizontal line of said character.

One of the machine's strong points is its sprite handling. Sprites are small graphics that can be moved over the screen without disturbing it. The CV can simultaneously display 32 hardware sprites, either at a size of 8x8 pixels, or 16x16. This is far more than its competitors of the time, but the advantages are somewhat dampened by the fact that each of these sprites is restricted to being a single color from the same palette used by the character graphics (actually, one color for the "set" pixels and "transparent" for all others). Making a multi-color object with them requires overlapping multiple sprites, one for each color desired. Furthermore, only four sprites may appear on a given horizontal line at once.

The Toolkit

It's one thing to decide to make a game on a system like Coleco's --developing for the console is another matter. Neither Kevin nor I had access to any of the tools used by the original developers of the system, but that wasn't important because we had at our disposal tools and technology far more powerful and flexible than the actual development systems would have been.

A couple of Colecovision emulators have been written for the PC, so code can be tested right on the PC, minimizing the need to burn EPROMs (Electronically Programmable ROM chips) or produce custom development hardware. Furthermore, Kevin wrote a series of utilities that would convert PC bitmap files (of a set size and using a specific palette) into character data digestible by the CV's finicky video hardware. Kevin also created a program to read a bitmap and check it to make sure there were never more than two colors on a line in a given character width. This program made quick detection and correction of problem pixels possible.

Image processing was carried out using the excellent shareware product, Paintshop Pro, by JASC Inc. Most of the actual pixel pushing was done with an old DOS animation program called PC Animate, written by Bill Marsh. It was a perfect choice because the animation buffer can be used to hold a virtually unlimited number of frames holding working versions of graphics.

An additional advantage in using PC Animate to create the raw graphics was that it was a simple matter to actually test the results in motion. For instance, as many of the elements for the game's first level were coming together, it was possible to see what the game would actually look like. I would animate the characters on the working background, illustrating the gameplay in action. This not only made it easier for Kevin and I to be sure what we were making, but just watching things moving suggested new ideas to us, which helped solidify gameplay mechanics before any actual coding began.

Unfortunately, as wonderful as these development tools are, the only way to accurately test the graphics is to get the graphics running on an actual console and see what the results are like on a TV set. An early test screen featuring a brick building looked fine on the emulator, but the thin vertical red lines defining the edges of the bricks bled like crazy on an actual TV and threatened to overwhelm the sprites making up the characters -- or so Kevin told me. I had to rely on his reports because I did not have the necessary hardware to burn EPROMs and to test them on the actual hardware, and Kevin lives 2,000 miles away. Thus, some evenings we'd spend alot of time on the Internet, me fiddling with a graphic, zapping him the file, and having him burn an EPROM and tell me the results.

Scanners and Sprites

A few years ago I created the graphics for the sample game included in a book written by my friend, Clayton Walnum (Windows 95 Game SDK, 1995, by QUE). In an attempt to give that game a "non-computer" look, I had created the monsters for it by drawing them on paper, coloring them with felt-tip markers, scanning them and then scaling and color reducing the resulting images to fit the graphics format required by the program. The characters created by this means were more fluid of line and form than would have been the case had they been drawn via mouse. Applying this technique to the CV game seemed a natural, given I wanted to avoid the crudity and stiffness that typifies most computer and videogame characters of the Coleco's era.

As a test, the game's title screen was generated using this technique. I drew and colored the required characters on paper. I wasn't terribly concerned about getting them positioned perfectly, as I knew I would end up tweaking the composition for best effect on the CV. Following scanning, the first steps of this process were handled using Paintshop Pro. I cropped and resampled the scanned image to CV resolution. That done, I used the replace-color function to bring the thousands of subtle color variations in the scan down to a few "legal" CV colors. So far so good, but the hard work was yet to come, because I still had the only-two-colors-per-eight-pixels-on-a-line limitation to deal with. Knowing this, the title image had been drawn with very large figures, thus large areas of single colors limited the number of problem areas, but some still existed. A great deal of time was spent fiddling with the image to move something a few pixels so as to maintain the two colors maximum per eight pixels rule.

Figure 3: Title screen scan and converted image.

In the end there were a bunch of places where it was just not possible to get the colors down to two without seriously truncating the image or losing a nice detail (like the button on the muscle-stud's jeans). Unwilling to compromise, I asked Kevin to use sprites to "patch" all the trouble images on the graphic. In most of the 18 cases where they were necessary, these patches are simple mattes of background color (black), but occasionally they are used for more obvious details (the aforementioned jean button). In the absence of a tool with which I could create these sprites myself, I simply drew these elements on a bilious green background, each in a 16x16 pixel box, and gave Kevin a coordinate list of where these items would have to appear on the screen.

The detailed title screen served an added purpose. Early tests of the game graphics left some people thinking the pixels that defined the edges of the muscle stud character's nose were his eyes (which are hidden by his hair). The title screen was designed to "plant" clear likenesses of the game's characters in the player's mind, thus eliminating such confusion.

Painting with LEGO

By the time I was well into the title screen, it was obvious that the scanned drawing technique would not be a suitable solution for most of the actual game graphics. While it worked fine for figures as large as those on the title screen, the characters in-game would be much smaller, and any scanned images would have to be retouched and tweaked so much that there was no real benefit to using that approach. Thus, these graphics were created in a more traditional approach...working in a zoom mode and placing pixels.

Pixel pushing at this low resolution and with so few colors makes it tough to create good looking graphics. It's a bit like painting with LEGO. The pixels are so big and the colors are so bright, it's like working with big colored blocks.

One thing that typifies graphics on these old consoles is their "flatness." Objects, characters and backgrounds are usually composed of a single color, and, less often, of two or three. Conversely, I was determined to use "modeling" (shadows) to flesh out the graphics, despite the two colors per eight pixels limitation. This turned out to be not much of a problem for the backgrounds, but really was extremely vexing where the muscle stud was concerned. The game's first level alone required over 25 different frames of animation for him -- a very large number for a game system of this era, and even more staggering considering that in most frames he consists of 28 characters. The number of frames and poses made it difficult to get the colors where they needed to be and keep the drawings from becoming blocky. In some places, such as the diagonals of his forearms in many frames, it was impossible to get around the problem. Unlike the title screen, sprites could not be used to patch the trouble spots. They were required for moving objects and running characters that would appear on the same horizontal line, and only four sprites can appear on a line. The ultimate solution was to "hide" the color problems with a simple trick: using the background color to draw hairs on his forearms, acting as breaks to hide the perfectly vertical color changes occurring at character boundaries.

Figure 4: Detail of stud's arm.

A couple of sprites were employed on him, though, to fix problems with his hair and to give him a set of pearly whites. These did not affect the four sprite per line limitation because he is so tall that his head is well above all of the other moving objects on the same level with him.

Spritely Tricks

As the game's smaller characters were to be able to move all over the screen and were not to disturb the background, character graphics were impractical. Sprites were the obvious choice, but the maximum limit of four sprites on a line was a serious consideration, particularly since the main characters required three colors unto themselves, hence three sprites. With three sprites tied up in each character, only one other sprite based object could appear on the same line with each of them.

Figure 5: Staggered sprites. Figure
Figure 6: Fixed up Donkey Kong.

Maurice Molyneaux has been involved in the computer industry since the mid 1980s, both as a graphic artist and game designer for companies such as Epyx, Omnitrend, Electronic Arts and Playmates Interactive Entertainment. He was a columnist for several Atari computer magazines, Video Games & Computer Entertainment and Morph's Outpost. When not working on 16-year-old videogame consoles, he spends his days working in game development at the San Francisco studio of Psygnosis.

Maurice Molyneaux

Kevin Horton

The copyright of articles and images printed remains with the author unless otherwise indicated.

At the time of this writing, we are still dealing with this issue, but one solution being tested is "staggering" the sprites, so that they don't perfectly overlap, For instance, in the case of the character of Anita, the only place the color blue is used is for her eye and hair, so in her case we shift the sprite up as high as possible and only use the bottom few rows of it for these features; this leaves only two composing the bottom 12 or so scan lines. Other objects are being similarly tweaked to stagger sprites onto different heights. Thus, we might have two characters facing each other, totaling six, but the various sprites are so staggered that any given scan line of the TV display only features the maximum of four.

The Wide World of Color

Arriving at the skin colors for the game characters was a hassle, because the 15 colors available were dominated by greens and blues, which left only white, gray, two sickly yellowish shades and a few reds to work with. I played with these colors on both the title screen and my test graphics, and was surprised to find that the best color for the character’s skin was the light red, with dark red for the shadows.

The restrictive palette made it difficult to balance the graphics. It was particularly tough to get the characters to stand out against detailed backgrounds because all of the colors were fairly bright. When you find your multi-colored character being graphically overpowered by a brick wall you immediately begin to understand why so many older games feature empty space wherever objects are required to move. I was determined not to go this route, so I simplified the backgrounds in places where moving objects would be; for instance, throwing the side of a building into shadow so that only the highlighted edges of the bricks would show, thus preserving a detailed background while keeping black the dominant color.

Defending the Caveman

I have long suspected that many old game consoles and computers were capable of displaying better graphics than the software for them belied. I have a few thoughts on why this was the case. First, the developers of that period didn't have the luxury of the sophisticated tools I used to do things like scan and process the title screen for our game, test animations of the character graphics on the fly and so on. Secondly, those games were typically the product of one person: a programmer. Artists were only infrequently involved in the creation of game graphics, and, in those cases where they were, most were probably inexperienced in pushing pixels.

As a parting illustration of what a machine like the Colecovision was actually capable of, a screen shot from its Donkey Kong cartridge is compared with my own rendition of same. The results are totally legal Colecovision graphics, using five sprites to patch a few trouble spots and add details like Kong's eyes and Pepsodent grimace.

Which version would you have wanted to play in 1982?