Using TextPlot For Animated Games

David Plotkin
Richmond, CA

When typing in this program, be especially careful when typing the numbers in the DATA statements and USR commands. A mistake could cause your machine to lock up, that is, no longer respond to the external world, requiring a power-on reset.

If you're like me, the first thing you did when you bought your new Atari was run out to buy some games for it, probably with visions of multi-colored, arcade-style entertainment in mind. The computer store where I purchased my Atari also sells Apples. The wide assortment of exciting, machine language games available on the Apple and not on the Atari was a real disappointment. Time and time again I saw fascinating games which were not available to me. The recent release of many new Atari programs has somewhat alleviated this, but the problem still exists. To make things even more frustrating, many interesting games are not all that complex from a programming standpoint.

I decided to try my hand at programming these games myself. Having completed the book on how to program in BASIC, I charged ahead and wrote my first ‘Arcade-style" game, which I entitled "Space Rocks." It was a home-grown version of "Asteroids." The program had it all: graphics, sound, multiple missiles in flight at once, a fancy space ship, scoring, and music. It was also extremely slow. I had spent two weeks on it and each move took almost a minute. Ridiculous? Of course. I tried to speed it up by simplifying the graphics, but never did get it running very fast.

The next step was to try writing a program in a text mode. The Atari can manipulate text quickly, and so I met with a limited success. Using a custom designed character set also added to the text-mode games. Nevertheless, when there is more than one character to move, it can still be quite slow. I briefly considered learning machine language, but it's not something I'm eager to tackle.

The program "TextPlot" (COMPUTE!, November 1981, #18) is a first-rate gaming tool. As the author said, it allows you to use text and text characters in graphics modes. It also works with an alternate character set, as also mentioned briefly. But here's the kicker — since it draws the text character (and erases it also) using a machine language routine, it can be used to animate in high resolution graphics modes at machine language speeds. Thus, your character "A" ; redefined to a space ship or missile, literally zips across the screen, and five or ten "A's" can move across the screen without the frustrating BASIC'S characteristic of "taking turns."

By drawing the non-moving portions of your picture in BASIC graphic mode, and the moving portion using TextPlot, you can write some colorful and challenging games. The program below demonstrates my own efforts in this regard, which I will tell you about shortly, but first some pointers:

1) Animation is done by drawing, erasing, and redrawing in a new position. The erasing can be done in two ways. You can call the USR command with the character ASCII code, but in the background color. Or you could call USR command with the ASCII code 32 (blank space) in any color. By looping and using a variable either in the color slot or in the ASCII code slot, drawing and erasing is easy. Increment the X and/or Y coordinates (such as MX1 and MY1 in the program) between erase and the redrawing, and the character moves smoothly across the screen. This incrementing, by the way, was done in BASIC (MX1 = MX + 1, etc.) and seems to be the limiting factor in how many characters can move across the screen at once without significant "taking turns."

2) It is possible to define a creature or object which consists of two or three refined characters which move together. It is best to increment the location of all three characters and then call the machine language routine to move them the most smoothly.

3) There is a large difference between vertical and horizontal resolution. Moving a character one space horizontally is equivalent to moving eight spaces vertically. Remember this when moving diagonally. Also, BASIC commands such as DRAWTO, PLOT, LOCATE etc. work on the graphic mode coordinate system. Thus, the horizontal location in mode seven can vary from zero to 159, but the X coordinate input to the USR call can vary only from zero to 19, normally. Therefore X coordinate = horizontal location/eight. The vertical resolution is the same as the Y coordinate.

Note that, in the program, I have varied the X coordinate from 60 to 79 instead of zero to 19. What this does is move the character down one pixel for each multiple of twenty (60 to 79 moves the character down three pixels from where it would be a zero to 19). A character moving horizontally will pass across the screen lower and lower at higher values of the X coordinate without changing the Y coordinate. This invalidates the relationships shown above between coordinates and screen position, which only work if the X coordinate is between zero and 19.

4) A LOCATE statement meant to find or detect one of the generated text characters does not care what the character is, only the color of the character. This is because the text character is just a series of pixels set to a particular color.

5) The alternate character set is located in an area of RAM protected by POKEing a lower number of pages into location 106, which stores the amount of pages (multiply by 256 to get bytes) available in memory. This is a fairly common technique of protecting memory, since the computer doesn't know about the memory above location 106 (see line 3200 in the program) and, thus, doesn't use it.

In the original version of the character generator, a step-back of five pages (1280 bytes) was used. The character set is four pages (1K) long, plus one extra. This works fine in Graphics mode zero, but does not work for this program. I found that the minimum step-back is 16 pages (4K), although any multiple of 4K (32 pages or 48 pages) will work. Intermediate values led to part of the screen being blank or runny dots and lines being displayed. I think this has to do with the display list not crossing a 4K boundary (the display list in Gr. 7 is right around 4K long, so it would have to be located on a 4K boundary) but I'm not sure. Perhaps a more advanced programmer could shed some light on this. A final point on this: after every GRAPHIC command, you need to include a POKE 756,PEEK(106) + 1 to point the Character Base address to the redefined character set, since the GRAPHIC command resets the pointer to the ROM character set.

Rules Of The Game

Now to the program. You are chief gunnery officer of the Space Fortress Reliable, located at the outermost fringes of the Galactic Empire. Although the fortress is protected by shields, there are four "channels" through the shields to allow for supply ships and transportation of personnel. Since attacking vessels can also make use of these channels, a big laser is mounted to fire down each of the channels.

The channels are located directly above, below, left, and right of the fortress. Their width is such that only one ship at a time can attack from any direction. The laser is aimed in the appropriate direction by pushing the joystick in that direction. Once the laser is aimed, it fires automatically.

As the attack progresses, however, and energy is used up, the shields begin to withdraw towards the fortress to maintain integrity. The enemy ships can come out of hyperspace and begin the attack through the channels closer to the fortress, so you have less time to fire on them. Watch out especially for the ships to the left and right which, although they start farther away than the ships above and below, move eight times as fast. Good luck, and good hunting.

Program Line No.	Description
1-10	Go to the subroutines for redefining the character set and initializing TextPlot.
20	Initialize graphics, set character base address to redefined character set.
30	Initialize variables.
40-100	Draw the fortress and background.
110-120	Print "SCORE 000" on the screen.
130-170	Erase last gun position.
180-220	Read current joystick position.
230-280	Aiming and Firing sequence. The gun is drawn in the new position, and the laser is fired. If the ship is hit, then it explodes.
290-310	Updates the score on the screen, dight by digit. Jumps to the end of the game on high score.
320-350	If a ship was destroyed, then uses the random number generator to decide whether a new ship is to be launched. The starting position of the new ship is moved closer to the fortress as the score increases.
360-400	Moves each ship toward the fortress, if the fortress is hit by a ship then jumps to the end of game routine.
500-620	End of game routine when fortress is destroyed.
700-710	End of game routine on winning game.
20000-20430	Subroutine for Textplot.
32000-32160	Subroutine for redefining character set.

Variables

SC = Score	J = joystick position
Jl = 1, 2, 3, 4 depending on joystick position
MX 1 to MX4 = X coordinate of enemy ships
MY1 to MY4 = Y coordinate of enemy ships
Ml to M4 = status of enemy ships; = 0
     when ship is blown up = 1 when ship is intact
Starx, Stary = X and Y coordinates of stars
ML = memory location
START = byte address of RAMTOP
Z, Y, STAR, N, W, I = loop variables.