A Self-Modifying
Player/Missile Graphics Utility
Kenneth Grace, Jr.
This excellent utility program removes much of the complexity from setting up player/missile graphics. It modifies itself into a skeleton program that can become the core of your game or graphics demo.
The utility in Program 1 sets up a skeleton program for Atari player/missile graphics. It presents a series of questions about the P/M situation you want to create and then modifies itself according to your responses. The resulting skeleton program includes some subroutines which you can use for controlling player and missile motion. They are based on string manipulations, so animation is also easy to accomplish.
I got the idea for this program after reading Bruce Frumker's article (COMPUTE!, August 1981, #15) on self-modifying programs. I hope this program will stimulate your thinking on other ways to use the self-modification capability built into the Atari.
There are several steps involved in setting up P/M graphics, and they have been covered in COMPUTE! and elsewhere. The steps are easy, but there are several choices available along the way (resolution, numbers of players and missiles, colors, initial positions, etc.). That's where this utility comes in.
It contains all the basic steps, and where there are choices to be made, they are presented to you. The program then uses Frumker's technique to add appropriate lines to the program. It also uses the same technique to delete lines that are not needed for your specific P/M setup, including the lines which ask the questions.
When the utility has finished, you are left with the skeleton of a P/M graphics program. You can LIST or RUN it at this point to check things out. But to make it a real program, you will have to draw the playfield and add the main loop for controlling motion, checking collisions, etc. In other words, the utility does just the P/M setup.
Since I make extensive use of Frumker's technique, I have split it into two subroutines, at 150 and 155. Between the two subroutine calls I put PRINT statements for the lines to be added to, or deleted from, the skeleton.
Aside from these two subroutines, the heart of the program is in lines 20-145. These lines present the series of questions through which you define your particular P/M arrangement. For example, lines 20-36 and 9020 take account of Fred Pinho's rules for placing P/M memory so that it doesn't overlap the memory for the BASIC GRAPHICS mode [see his articles elsewhere in this book]. The self-modifying feature is used after every question or two to add the appropriate statements to the setup section beginning at line 9000. At a few places the program STOPs while you enter DATA statements containing the bytes defining the shapes of the players and missiles.
Also scattered through this section are lines, such as 18, which delete the preceding lines, or delete the missile motion subroutines (when you have no missiles), or delete other unneeded lines in the section starting at 9000. If you have done any program editing on the Atari, you no doubt are aware of the keyboard "lock-up" problem. With all the deletions in this utility, I am almost inviting this disaster. Indeed, it cropped up many times as I was developing it.
Seemingly minor changes in the program would make the difference in whether it showed up or not. I say all this by way of warning. If you key in Program 1 exactly as shown, it should work OK. But if you decide to make improvements to it, you might run into the lock-up problem for certain combinations of inputs.
When the utility has finished running, you are left with lines 1, 159, appropriate subroutines from 160-198, a trivial loop at 200, and the P/M setup steps starting at 9000. Starting from this skeleton, I suggest that you use lines 2-158 for REMarks, opening titles, instructions, other subroutines, etc., and begin your main program at line 200. Additional setup steps, such as drawing the playfield, could go at the end of the section at 9000.
Motion Using Strings
I have included subroutines for player motion which use string manipulations. This method is described in George Blank's column in the April 1981 issue of Creative Computing.The basic idea is that you trick your Atari into treating the player/missile memory as the string array storage area for strings P0$, P1$, P2$, P3$, and M$. Lines 1 and 9500-9580 do this. You can then use Atari's fast string-handling routines for vertical motion or animation of the players.
In order for this to work, P0$,...,M$ must be the first variables mentioned in the program. You can assure this by turning off power momentarily and then typing line 1. In line 9500, VTAB is a pointer to the start of the variable table, which contains eight bytes for each variable. ATAB points to the start of the string array table, which is where the actual values are stored. Each pass through 9510-9580 modifies the eight bytes for Px$ (P0$, P1$, etc.) in the variable table, including the offset from ATAB where the actual values are stored (the P/M graphics memory).
The bytes defining the players are stored in strings D0$, D1$,... at lines 9090, 9140, etc. Each character in a string is stored in memory as a byte containing the corresponding ATASCII value. In this case, we want our data BYTE treated as though it were already an ATASCII value, so we use Dx$(I,I) = CHR$(BYTE). Note that this is a different way of using strings for P/M from Alan Watson's method (COMPUTE!, September 1981, #16). The demo (Program 2) mirrors Watson's example.
The descriptions Dx$ and DMx$ are initially read into P/M memory (i.e., into Px$ and M$) at lines 9600-9680. The string B$ is a "blanking" string; it is filled with ATASCII values of zero at line 9070.
I have included two subroutines for player motion. The routine at 160 handles vertical moves of one or two units. The strings Dx$ are set up to include two blanks (ATASCII zero) at the top and bottom of each player description. Thus, small vertical moves can be accomplished by writing Px$(Y(P) + DY) = Dx$. The blanks in Dx$ will make sure that the old image is wiped out. The variable P is a pointer to the player being moved (0, 1, 2, or 3); its value is set by your program before the subroutine is called, as are the position changes DX and DY. Incidentally, the array variables X(), Y(), and L() hold the horizontal positions, vertical positions, and vertical lengths of the players. The corresponding variables for missiles are XM(), YM(), and LM().
The routine at 170 handles larger moves by blanking out the old player image with B$, changing the horizontal position to X(P) + DX, and rewriting the player image into Px$ at the new vertical position Y(P) + DY.
Vertical motion of a missile is slightly more difficult. The problem is that all four missiles are stored in the same memory block. Each missile occupies a two-bit slice of the eight-bit bytes in this memory block. Thus, we cannot simply write whole new bytes or blanks into this memory.
Instead, using a machine language routine, we do a logical AND of the existing memory with a binary mask, such as 11110011. This erases the old image in the appropriate two-bit slice, but leaves the rest of the missiles unchanged. Then we ADD the new image from DMx$. Since this image has zeros outside the two-bit slice, it won't affect the images of the other missiles. All of this is done at the vertical position of the new image. If there is a substantial vertical move involved, then two calls to the machine language routine are necessary: once to write B$ at the old position and once to write DMx$ at the new position.
Lines 9700-9740 read the machine language routine into the string MOVE$. The missile motion subroutine at 180 makes a USR call to this routine. The last variable in the USR call is the decimal equivalent of the binary mask. This subroutine assumes that vertical moves will be limited to one or two units (analogous to the player routine at 160). The subroutine at 190 handles the larger moves (analogous to the player subroutine at 170).
The Demo Program
Program 2 presents a demonstration of the use of the utility and motion routines. The demo attempts to duplicate Watson's animation program in COMPUTE! #16. The top part of the listing shows the answers you should give to the questions presented by the utility. The bottom part shows the lines to be added to the skeleton. Lines 300-530 match Watson's line numbers as closely as possible. A comparison of this demo with Watson's shows that the motion here is slightly faster--listen to the rate of the marching feet.
Finally, a word of caution: after keying in Program 1, save it on tape or disk before you run it. If you don't, you will find that a lot of your hard work has been wiped out.
Program 1. Player/Missile Graphics Utility.
Download P144L1.BAS (Saved BASIC)
Download / View P144L1.LST (Listed BASIC)
Program 2. Animation Demo.
RUN the utility in Program 1 and give the following answers:
Graphics Mode: 18
Resolution: 0
Number of Players: 1
Color, intensity: 1,6
Width: 0
Horizontal Position: 127
Length: 9
Vertical Position: 63
9100 DATA 126,90,66,60,219,189,102,102,231
CONT
Number of Missiles: 0
Priority: 1
Then add the following lines to the skeleton program:
Download / View P144L2.LST (Listed BASIC)Return to Table of Contents | Previous Section | Next Section
