Spotlight › Tank Attack

Tank Attack

Drive across a flat plain, dodge cubes and pyramids, and shoot enemy tanks that turn toward you and shoot back. It follows the 1983 MS-DOS port of Atari's 1980 arcade game, and it exists to give the drawing code something hard to do.

lines a frame
about 100
graphics cards
3, one code path
screen clears
none, ever
Tank Attack
Tank Attack in play, filling the whole screen. A blue horizon line runs across the middle with low hills on it, a white gunsight is centred, a magenta radar circle with a sweep arm sits above, the score reads HIGH 0 and PL 1 with four lives, and a cyan wireframe block stands to the right of the gunsight.
In play. The horizon, the gunsight, the radar and one obstacle. Every line on this screen is drawn by the game itself -- the operating system's drawing code is not involved at all.

The game

Short version: it is Battlezone.

You are in a tank, looking out of it. The plain is empty except for solid shapes you cannot drive through, and enemy tanks that hunt you. The radar at the top shows what is around you and which way it is. If you are slow, they shoot first.

Arrow keys or A, D, W and S drive. Space fires. P pauses, Escape leaves. There is a high score table, kept on the disk between sessions.

Unlike every other program on os8088, it does not run in a window. It takes the whole screen and puts the graphics card into a mode of its own choosing, then hands the machine back when you quit.

On screen

The same world on very different hardware.

Tank Attack
The Tank Attack title screen inside a window on the os8088 desktop. The words TANK ATTACK are drawn in cyan outlined letters, a green HIGH SCORES table lists four entries, white text reads ARROWS OR A D W S DRIVE, SPACE FIRES, P PAUSES, ESC OR F LEAVES THE GAME, and magenta text reads PRESS F TO PLAY.
The title screen. The lettering is drawn with the same line-drawing code the game uses -- there is no font here, just strokes.
Tank Attack
Tank Attack after turning: the hills along the horizon have moved to different positions, the radar sweep has rotated, and the obstacle now sits further right. One life remains.
After turning. The hills and the obstacle have moved together, and the radar has turned with them.

Three cards, three answers

A VGA gets 320 by 240 in 256 colours. A CGA gets 320 by 200 in four, using the same colours as the 1983 port. A Hercules card gets a 640 by 200 box in the middle of its screen, because filling all 720 by 348 pixels would be more than twice the work on the card that can least afford it.

The world is the same on all three. How wide you can see is fixed, and how tall is worked out from the shape of the card's pixels, so a square is square everywhere.

Why it does not flicker

The one problem that decided the whole design.

Clearing the screen is too expensive

The usual way to draw a frame is to wipe the screen and draw the new one. On a 4.77 MHz 8088 that wipe alone is about 50 milliseconds -- a whole frame's time, spent before a single line is drawn.

So nothing is ever wiped. Each frame remembers, row by row, exactly where it put ink. The next frame erases those runs and nothing else.

Erasing must also be invisible

Cheap is not the same as unnoticeable. If you erase and redraw on the visible screen, there is a moment when the picture is half gone, and the eye catches it.

On a VGA the game draws the next frame on a second page of video memory and switches to it. The other two cards have no room for a second page, so the frame is built in ordinary memory and copied across in one pass. Either way every pixel that reaches the screen is written once per frame.

What that is worth, measured

Forty consecutive displayed frames were captured on both black-and-white cards and each was compared with the frames on either side of it. Not one was thinner than its neighbours. An earlier ordering of the same work left more than half the frames less than half drawn.

Why measure it that way

A flash is a dip, not a dark frame. A scene that legitimately loses half its lines -- because you turned away from everything -- stays dim for a while and is perfectly fine to look at.

Comparing every frame against the middle of the run scored the same unchanged game at 99.9% one time and 55.6% the next, which is a measurement that cannot be used. Comparing each frame against its immediate neighbours answers the question actually being asked: did the picture drop out for one frame and come back.

This is the reason the game exists in the source tree at all. It is a load for the drawing code, on the side of the system where the operating system does not draw anything and the program owns every pixel.

Play it yourself

On the software disk, in the games folder.

  1. Download os8088.img and apps.img from the releases page.
  2. Boot the first in drive A: with the second in drive B:.
    qemu-system-i386 -drive file=os8088.img,format=raw,if=floppy -boot a \
      -drive file=apps.img,format=raw,if=floppy,index=1 \
      -chardev msmouse,id=m0 -serial chardev:m0
  3. Double-click the drive B: icon, then GAMES, then TANK.O88.
  4. Press F.