cibomatto2002
Windows 10
The need for speed
Early games needed fast-moving screens full of action. One obvious way to do this is to simply have a framebuffer representing the image, and the CPU performs animation by updating the framebuffer. Early CPU-controlled games like Space Invaders did just that. However, you'll notice that games on that hardware typically didn't do much drawing per frame, and in Space Invaders when the whole armada is moving it's noticably sluggish. Simple math reveals why: these systems used 8-bit CPUs at typically 1 or 2 MHz. If you assume an average 320x240 resolution, even at Space Invaders' 1 bit per pixel, there are (320 * 240)/8 = 9600 bytes of RAM in the framebuffer to update. Assuming a highly idealized rate of updating 1 byte every 2 cycles, that means you need to be running at least 1.2 MHz just to update the screen at 60 frames per second. And that's not including AI, sound, and other game logic.
Making it worse
This got worse when color was introduced: suddenly that 9600 bytes becomes 19200 bytes for 4 colors or 38400 bytes for 16 colors, with corresponding CPU requirements increasing to 2.3 and 4.6 MHz, which starts to be out of the reach of affordable early 80s microprocessors.
The fix
The fix came from text-only display terminals. These devices split the screen up into rectangles of pixels formed from a fixed number of horizontal and vertical pixels, such as 7x9 or 8x8. In this way, the CPU can cause an instant change to all the pixels in a cell to a different letter pattern by changing a single byte in memory. Game hardware designers realized that if the "font" was changed to include the building blocks of pictures in addition to letters and numbers that this system would allow large-scale animation quickly at a low cost in CPU cycles.
Returning to our example of a 320x240 screen, tilemaps typically used 8x8 pixel cells (called "tiles"), so video RAM in this case would be only 1200 bytes. The same math as before reveals that you can change the entire screen at 60 frames per second in only 144,000 CPU cycles, or about 10% of a typical 1 MHz microprocessor. This is far more manageable. If you use 2 bytes per cell to get a far greater available graphical variety (65,536 pieces instead of 256), it's still only 20% of the CPU time.
Better still, increasing the color depth meant no change to the size of video memory or the amount of CPU required to update it. The CPU didn't need to care if each 8x8 tile was 2, 4, 16, or 256 colors. The video hardware obviously did, but it's the CPU we're most concerned about. And from the CPU's perspective this technique is a major work saver.
Read more here
http://mamedev.org/devwiki/index.php/Tilemaps
Early games needed fast-moving screens full of action. One obvious way to do this is to simply have a framebuffer representing the image, and the CPU performs animation by updating the framebuffer. Early CPU-controlled games like Space Invaders did just that. However, you'll notice that games on that hardware typically didn't do much drawing per frame, and in Space Invaders when the whole armada is moving it's noticably sluggish. Simple math reveals why: these systems used 8-bit CPUs at typically 1 or 2 MHz. If you assume an average 320x240 resolution, even at Space Invaders' 1 bit per pixel, there are (320 * 240)/8 = 9600 bytes of RAM in the framebuffer to update. Assuming a highly idealized rate of updating 1 byte every 2 cycles, that means you need to be running at least 1.2 MHz just to update the screen at 60 frames per second. And that's not including AI, sound, and other game logic.
Making it worse
This got worse when color was introduced: suddenly that 9600 bytes becomes 19200 bytes for 4 colors or 38400 bytes for 16 colors, with corresponding CPU requirements increasing to 2.3 and 4.6 MHz, which starts to be out of the reach of affordable early 80s microprocessors.
The fix
The fix came from text-only display terminals. These devices split the screen up into rectangles of pixels formed from a fixed number of horizontal and vertical pixels, such as 7x9 or 8x8. In this way, the CPU can cause an instant change to all the pixels in a cell to a different letter pattern by changing a single byte in memory. Game hardware designers realized that if the "font" was changed to include the building blocks of pictures in addition to letters and numbers that this system would allow large-scale animation quickly at a low cost in CPU cycles.
Returning to our example of a 320x240 screen, tilemaps typically used 8x8 pixel cells (called "tiles"), so video RAM in this case would be only 1200 bytes. The same math as before reveals that you can change the entire screen at 60 frames per second in only 144,000 CPU cycles, or about 10% of a typical 1 MHz microprocessor. This is far more manageable. If you use 2 bytes per cell to get a far greater available graphical variety (65,536 pieces instead of 256), it's still only 20% of the CPU time.
Better still, increasing the color depth meant no change to the size of video memory or the amount of CPU required to update it. The CPU didn't need to care if each 8x8 tile was 2, 4, 16, or 256 colors. The video hardware obviously did, but it's the CPU we're most concerned about. And from the CPU's perspective this technique is a major work saver.
Read more here
http://mamedev.org/devwiki/index.php/Tilemaps
