Player Missile Graphics .... using strings

by David Eaton


Issue 9

May/Jun 84

Next Article >>

<< Prev Article



The introductory article on Player Missile Graphics in the last issue mentioned one of the problems in using Player Missiles from Basic which is the lack of registers to control vertical movement. Moving players up and down the Player Missile area byte by byte is so slow that it is a nonsense to try it but there is fortunately another method which not only gives fairly fast vertical movement but also allows instant changes in player shapes. What is more no machine language is involved!

The method uses strings to hold all the player missile data and this has two main advantages.

1. Basic automatically sets aside and protects an area of memory for each string so that player missile graphics do not have to be protected at the top of memory.

2. Atari Basic has very fast string manipulation commands so that we can move segments of strings, copy one string to another etc. at great speed. Because the player missile graphics occupy the same area as the string being manipulated, any change is immediately displayed in the player.

To set up player missile graphics in this way we must first DIMension a string to hold all the players. This string must be the first variable of any kind defined in order that it may be the first entry in the variable name table. It is safer if the appropriate line is the first thing typed so it is suggested that you turn off your computer and switch back on again before typing line 10 DIM PM$ (2048). Typing NEW won't do for, although this erases any program from memory, it does not clear the variable name table.

From here on we will be referring to the program listing accompanying this article and you should therefore look at the listing as we go through. We have already dealt with the DIMensioning of the string to hold our players but note that we are using double line resolution players which requires 2048 bytes of memory using this method and not the usual 1024. If we were using single line resolution we would DIMension PM$(4096). Having DIMensioned the string we must clear it of any unwanted garbage which we do in line 20.

Let's jump ahead now to line 90 as we need to find the starting address of the string. We use the ADR function for this but there is a problem in that player missile graphics must start on a 1K boundary for double line resolution or a 2K boundary for single line. When strings are DIMensioned, they are given the next available address in memory which is seldom an even kilobyte address so, having determined the address of our string, we must add an offset to allow the player missile graphics within the string to reach the next boundary. We must allow for a maximum offset of 1023 bytes and this is the reason for DIMensioning PM$ to 2048 even though double line resolution requires only 1024 bytes. A calculation is needed to get the starting address of the player missile base address PMBASE within the string and this is done in lines 100, 110 and 120. If you recall from the last article, we must tell ANTIC where to find the player missile graphics which we do in line 130.

We will come back to the variable S later but in the meantime we need to set up a few more strings so let's go back to line 30 of the program. PM$ holds the player missile area but we also need a string to clear images and also a string for the players. If you have not already typed in the program, let me explain that the player used is an arrow which can be moved about the screen and will change to point to the direction of movement. This could just as easily be a space ship or any image you desire. The arrows are 8 lines high although the left and right arrows have one blank line, but we must leave a number of blank lines to cover up the overlapped player image as we move it about in the string otherwise a trail would be left on the screen. The speed at which a player can be moved is determined by how many lines it is moved up or down the screen. We will start moving the player one line at a time and allow for up to six lines so we must leave 6 blanks before and after each image. As each player can be at any of 128 positions in its area of memory, we must also DIMension a string of 128 characters to clear any image. We will call this string CLEAR$ and it is DIMensioned and cleared in line 30.

The four players are put into PLAYER$ in lines 40, 50 and 60 with the DATA for the players in lines 70 and 80.

Let's now get back to that variable S which we will use to define the position of each player. In line 140 we define the position of player 0 by adding 512 to S. If you refer to the table in the last article, you can find the values to add for each of the other players and the missiles.

We are now ready to add other parameters such as colour, size etc. which were all explained in the last issue and these are included in lines 150 and 160. To place the player on the screen we use line 170 to define the horizontal position and line 180 for the vertical position.

The variable IMAGE is set to the position of each player image in PLAYER$ and is initially set to the first arrow. By changing the value of IMAGE to the position of each image in PLAYER$, we can instantly change the shape of the player on the screen. Each arrow is 20 lines high including six blanks at either end but as the blanks at the beginning of each arrow overlap those at the end of the previous arrow we set the value of IMAGE at 1 for the first image, 15 for the second, 29 for the third and 43 for the fourth. To place an arrow on the screen we must transfer the portion of PLAYER$ containing the arrow into PM$. The position we place this in PM$ determines how far up or down the screen the arrow appears. Line 190 does this and by simply changing the value of Y we can move the image vertically.

If you have not already done so, type in the program and see how the player responds to the joystick. Pressing the fire button will change the speed of movement but if you let the speed become greater than 6 you will see what happens when there are not enough blanks at the end of the image. To clear the screen just press any key which will bring our CLEAR$ into play in line 290. The player is cleared instantly.

The main disadvantage of the method is memory consumption but it is a very versatile way of using player missile graphics and certainly a lot easier to learn than machine language

AtariLister - requires Java