With Player Missile Graphics it is possible to move images you
create around the screen independent of what is displayed as
background. This is done with very little calculation. Changing a
single memory location will move the entire image horizontally while
moving bytes up and down in memory will move the image vertically.
I've developed a set of machine language routines which can be
called from Basic to assist in missile graphic movement. These are not
necessarily the best and certainly not the only way of doing missile
graphics, but I hope what I've come up with will help others in
developing programs.
I'll cover only enough to get started in this article. I placed the
routines in the unused portion of memory in page six and have reserved
some locations at the top of page six. You often have to remember
vertical and horizontal positions of players. Table 1 lists locations
for this. Also listed are locations storing pointers to areas of
memory used to hold player images. These have to be calculated because
they depend on the size of memory in your machine.
|
MISS
|
Plyr.
3
|
Plyr.
2
|
Plyr.
1
|
Plyr.
0
|
Horizontal
Position
|
1788
53252
|
1787
53251
|
1786
53250
|
1785
53249
|
1784
53248
|
Vertical
Position
|
1783
|
1782
|
1781
|
1780
|
1779
|
High
Byte Memory Vector
|
1778
|
1777
|
1776
|
1775
|
1774
|
Low
Byte Memory Vector
|
1773
|
1772
|
1771
|
1770
|
1769
|
Perhaps the best way to explain what is going on is through an
actual program. The listing is from a program called Lunar V. The
machine language subroutines are poked into memory in lines 30-44.
Line 36 contains a subroutine used to load zero page locations OOCB
and OOCC with the start of memory assigned to player X. Players are
numbered 0 to 4 with player 4 being missiles. At line 38 is a routine
which places bytes representing player X into memory at the
appropriate spot. It is called using the USR function in the form
A=USR(1606,X,ADDR). ADDR is the decimal address where player image
bytes are stored. The routine will keep loading bytes until a zero
byte is found. It picks up the vertical position (increasing down from
the top of the screen) from 1779,X. The load player routine does not
erase what is already there. This is done by a routine poked in at
line 44 and called by A=USR(1706,X).
Major routines move the player vertically. A=USR(1637,X) poked into
memory by lines 40 and 41, moves him downscreen and A=USR(1673,X) in
lines 42 and 43 move him upscreen. Traps are included to keep from
roaming into another player's area of memory. These can also be used
to limit the vertical motion of players. Change the 126 at 1678 (make
it lower), or the 1 at 1683 (make it higher).
Setting pointers for player memory is done in line 50. These are
for double line resolution meaning each byte will cover two scan lines
on the TV. You could get smoother motion using single line resolution,
but double line resolution is simpler for now. The 4 page gap (1 K)
between the end of player memory locations and the end of RAM is used
by the operating system for display purposes, the amount used depends
on the graphics mode.
Lines 60 and 63 poke data for images into memory. The images (in
order) are the lander, the flame and the crater. Various portions of
the flame are used depending on the thrust (see line 195). Images are
stored in an unused portion of memory at the beginning of the missile
graphics area.
____________
I believe that Lunar V was Stan Ocker's first program submitted
to the A.C.E. Newsletter in June 1981. Stan has come a long way since
then but I hope that this article and program will provide readers who
do not understand yet about Vertical Blank Interrupts, with a better
understanding of player missile graphics. See if you can improve the
program, there is plenty of scope, and send in your revised efforts.
|
|
![](../download.gif) |
top