| Articles posted June 2007 |
The Universal Platform, Part 1
It's interesting looking back at some of the early arcade game platforms and realizing just how much they share in common. Certainly, the Taito's classic Space Invaders hardware was a very popular generic platform which was adopted, copied, hacked, and modified to support a large number of different games. Following on the heels of that success, Namco's Galaxian hardware design became its heir apparent.
On the surface, both Space Invaders and Galaxian share a number of similarities. Both games were vertically oriented space shoot-em-ups. They both had a large number of invaders approaching from above, raining bombs on the player. They both had player ships that could only move left or right, and fired missiles up at the incoming invaders. Certainly when I was a kid and knew nothing about the hardware involved, I thought of Galaxian as a sort of super Space Invaders, since the Galaxians would actually swoop down to attack you, which seemed like a neat trick.
From a hardware perspective, however, the two platforms were quite different. Sure, they both used the Zilog Z80 to power the gameplay (technically, Space Invaders was powered by an Intel 8080 CPU, which was the Z80's architectural starting point). But the video architecture was very different between the two.
Space Invaders was based off of a very computer-like concept of a bitmapped display, where each pixel was carefully drawn one at a time by the main CPU. This had some nice advantages in that the game code had full flexibility on what to draw where. It also had the disadvantage that it required a lot of work to erase and redraw the player and enemy graphics each frame. If you ever look closely at the invaders, you will notice that they don't smoothly move all at once, but rather you can watch a ripple effect happen as they are updated in columns. This is because there wasn't enough CPU power to erase and redraw all those invaders on each frame. Keep in mind that a typical arcade game is approximately 256 pixels by 256 pixels, so even just clearing the screen requires 256x256 = 65,536 operations. If each operation takes 4 clock cycles, then that is about 1/4 of a second on a 1 MHz CPU! Now, in reality it's not quite that bad: because the display is black & white, each pixel only requires 1 bit, so you can pack 8 of them into one byte and reduce the number of operations by 8. Still, 1/32 of a second is still two whole video frames.
In contrast, instead of a bitmapped display, Galaxian's video was built out of tilemaps and sprites, a video design that eventually became the norm for arcade games throughout the 80's and 90's. A tilemap essentially divides the screen area into a number of 8 pixel by 8 pixel squares. Rather than being able to draw each pixel independently, the game CPU instead chooses which one of 256 possible pre-designed 8x8 graphics tiles will appear in each square. These graphics tiles are stored in a separate ROM from the game code. Of course, one of the tiles is always a blank square, so to clear the screen, you would need to set each of the tiles to display the blank square. Taking the Space Invaders example above, a game with 256 by 256 pixels would need a 32 by 32 tilemap to cover that area with 8x8 graphics tiles. To clear the screen (i.e., set each tile to display the blank square), it requres 32x32 = 1,024 operations. At 4 cycles per operation, clearing the screen happens in a brisk 1/250th of a second for a 1 MHz CPU.
Of course, you lose a lot of flexibility when switching from a bitmapped display to a tilemapped display, but you gain a lot in speed. The biggest limitation of tilemaps is that you can only position your tiles on 8-pixel boundaries. This makes it hard to smoothly animate anything because you can only move objects across the screen 8 pixels at a time, which is very chunky and distracting. To overcome these limitations, the Galaxian hardware included two additional features that gave the designers the flexibility they needed to produce smooth animation: column scrolling and sprites. I'll talk about those in Part 2.
Slaying the Beast
It is a thing of legend, known for years, and yet never confronted. It has grown out of control ever since the earliest days of 1997. It has branched and forked, taking over dozens of source files. Years have passed and many features have been added to ease its burdens. And yet, this code remained largely as it was since its inception.
Occasional brave adventurers have stepped in from time to time, seeking to add yet another game to its hideous bloat. But they all quickly recognized the horror and fultilty, frantically ignoring similarities to other games, instead just focusing on getting in and getting out as quickly as possible.
And so the behemoth grew.
But something stirred within me. I noticed many games using colortables needlessly. And that included every single game intertwined with this terrible monster. The thought occurred to me to fix up the video timing as well. Just a simple change, really.
And then I saw stars. And they looked like of like the stars of Astrocade, except done badly. Consulting the schematics revealed fundamental flaws in the driver's video design. The potential impact was too great! What should I do? Turn away yet again? Leave it for a distant future, or another soul braver than I?
No. Not this time.
Schematics in hand, years of history against me, I stand now to face this beast. And I will make it clean.
Yes, the foul galaxianscramblefroggeramidarscobra beast will be tamed. Or I will die trying.
Wish me luck.