| << Newer | Article #101 | Older >> |
All about blitters
A number of games I've done drivers for — Williams, Strata, Art & Magic, etc — use blitters as their way of drawing graphics on the screen. This is different from the way most arcade games work, and is actually much more similar to a modern computer. In these games (and in computers), there is a large chunk of video memory which is called the "frame buffer". The frame buffer contains 'n' bits of information for each pixel you see on the screen.
Now, one immediate problem you run into with a frame buffer is that there is some hardware that is constantly scanning through this memory and pushing that data to the screen. If you are in the middle of modifying a bunch of pixels and the scanner intersects the area you are drawing to, then you can produce an effect called "tearing", where a partially rendered object is displayed (this is a simplification, but it illustrates the general idea). To get around this, most blitter-based games have two frame buffers. At any given time, one of the frame buffers is actively being scanned and displayed to the screen, while drawing happens to the other frame buffer. After the beam has scanned to the bottom of the display, the two buffers are swapped. This is known as "page flipping".
The early Williams games didn't have enough video RAM to do page flipping, so they had to be very aware of what scanline was currently being displayed. Once the scanning beam had passed below the area of video RAM they wanted to animate, then they could make their changes without fear of tearing. This is generally referred to as "drawing behind the beam".
So where does a blitter come into play? Well, in general it was entirely possible to sit there and muck about with the frame buffer using the main CPU. In fact, Defender doesn't have a blitter at all — it is all drawn by the main CPU. The problem is that it takes a lot of CPU power to draw lots of pixels on the screen. And although a CPU can certainly accomplish a lot, it is not specifically designed for drawing lots of pixels at high speeds. One solution to this could be to add a second CPU that is responsible for drawing the graphics, based on commands from the first CPU. In fact, a number of games such as Gyruss and the Cinematronics/Leland games (Quarterback, Ataxx, Super Off Road, etc) do just that.
However, a CPU is an expensive part. And it's not optimized for doing graphics. So a number of folks caught onto the idea of designing custom ICs that were dedicated to performing very fast graphics operations. In general, it's not enough to just draw pixels, these chips also had to do a lot of bit manipulation and address computations to handle things like X and Y flipping, transparency, scaling, etc. The term that has come up over time to describe this kind of operation (copying large arrays of data and manipulating them during the copy) is a "blit". And custom chips that are dedicated to this sort of work are called blitters.
So, you can think of a blitter as a custom chip that is designed to copy graphics (which are normally stored in ROM or RAM) to a frame buffer while manipulating the data in a programmed fashion.
So what makes this tricky in MAME? Well, first off, every company designed their own blitter. There is no standard way of blitting. Generally, this just takes some reverse engineering power and a lot of patience to figure out what's happening.
The really tricky part is the fact that blitters don't perform their operations instantaneously — it takes some time to actually shuffle through all that data and render it to the frame buffer. As a simplification, most blitters in MAME are implemented as "instantaneous" blitters, meaning they complete instantly. The problem is that many games rely on the speed of the blitter to limit their speed, or else overtax the blitter so that the original game slowed down when too much was being drawn at one time. Figuring out how fast the blitters operated is the trick, and I'll talk more about that next time.