No Fragments Archive 10: Diskmags/nf_archive_10.iso/MAGS/ST_USER/1990/USERAU90.MSA/TEXT_STOS.DOC

Text File | 1990-06-24 | 8KB | 176 lines

                           ON THE REBOUND


            Phil Lawson continues his STOS BASIC tutorial and
           introduces a clever way to get your sprites bouncing


This month we'll continue to explore sprite commands and pay particular
attention in getting objects to bounce around the screen. (I had hoped to get
the sprite path definer completed for this month's issue, but several problems
cropped up - including a duff disk drive - which means I'll have to postpone it
for a while.)

    Anyone remotely interested in games playing will have heard of Breakout, or
its famous 16 bit grand-child Arkanoid. These games are very simple in concept
and the major programming headache is checking whether the ball has hit an
obstacle and calculating the resulting direction when it has.

    To illustrate these points load and run STOS.BAS from the cover disk.
You'll see a ball moving around a simple maze, with deflectors at each corner
changing the ball's direction. The big question is how does the program work?

10 REM Rebounding ball demo
20 MODE 0 : KEY OFF : CURS OFF : HIDE
30 DIM b(4,4),dx(4),dy(4)
40 dx(1)=-1 : dx(2)=0 : dx(3)=1 : dx(4)=0
50 dy(1)=0 : dy(2)=-1 : dy(3)=0 : dy(4)=1
60 b(1,1)=2 : b(1,4)=3 : b(2,1)=4 : b(2,2)=3
70 b(3,2)=1 : b(3,3)=4 : b(4,3)=2 : b(4,4)=1
80 RESERVE AS SCREEN 10 : UNPACK 5,10 : WAIT VBL
90 SCREEN COPY 10 TO BACK : WAIT VBL
100 SCREEN COPY 10 TO PHYSIC : WAIT VBL
110 SPRITE 1,303,160,1 : xp=303 : yp=160 : WAIT VBL
120 d=2 : REM 1=left,2=up,3=right,4=down
140 WHILE-1
150 c=DETECT(1) : IF c>0 THEN GOSUB 190
160 xp=xp+dx(d) : yp=yp+dy(d)
170 SPRITE 1,xp,yp,1 : WAIT VBL
180 WEND
190 REM Find out the angle of the barrier
200 LOGIC=BACK : p1=POINT(xp-1,yp+1) : p2=POINT(xp-1,yp-1)
210 p3=POINT(xp+1,yp-1) : p4=POINT(xp+1,yp+1) : LOGIC=PHYSIC
220 number=0 : IF p4>0 THEN number=4
230 IF p3>0 THEN number=3
240 IF p2>0 THEN number=2
250 IF p1>0 THEN number=1
260 REM number is now 1,2,3 or 4
270 REM get the new direction by using number and the old direction
280 d=b(number,d)
290 RETURN

    This is a very simple demonstation which only allows the ball to move
either vertically or horizontally. We'll cover the more complex diagonal
movements in a future article.

    Lines 30 to 70 set up a series of arrays which contain all the directional
information, dx(4) and dy(4) hold the x and y increments for each of the four
possible directions - left, up, right and down. For instance, if the ball is to
move right (3), all we'd have to do is keep adding dx(3) and dy(3) to the x and
y values of the sprite. The array b(4,4) is used to calculate the new direction
when the ball hits an obstacle and we'll examine this in more detail later.

    For this demonstration program I could have set up a zone at each of the
corners and simply checked when the ball moved into one. However, this wouldn't
take into account the original direction of the ball, which as Figure I shows,
decides the new direction.

STOSPIC.PC1:<<SCREENSHOT>>

    Another problem that occurs when using zones is that depending on your
screen design they may overlap. This doesn't sound serious until you realise
that the ZONE function only returns the first zone number the sprite is in and
ignores any others. So, the ZONE result returned may not be the one you want.

    A more precise way of testing whether a sprite has hit something is to
place the hot-spot of the sprite at its centre and constantly check the colour
of the background screen under the sprite with the DETECT command, the syntax
of which is:

x = DETECT(sprite-number)

    The returned value of x will be the colour number directly under the
hot-spot. Therefore, if we use a particular colour to draw the objects the ball
should bounce off, we can test for it with DETECT and change direction when the
right colour is found.
    Try adding the following line to the demonstration program to see the small
points of colour which I've used to determine when the ball should change
direction.

105 COLOUR 7,$777

    Just looking for the colour won't tell us the angle which the ball hits the
object, and therefore we cannot determine the new direction. This is where a
little mathematics is used.

    Figure II shows a ball hitting an obstacle, with the centre point just
touching the edge. Around the centre are four other points - P1,P2,P3 and P4.
By testing the colours under these four points we can work out the angle of
impact.

STOSPIC.PC1:<<SCREENSHOT>>

    In the first only P1 will be set, no matter which direction the ball is
travelling in, and the other three points will be zero. The same is true for
P2, P3 and P4 in the other examples. To see this for yourself try adding the
folowing line:

255 LOCATE 0,0 : PRINT p1,p2,p3,p4

    If x and y represent the centre coordinates of the ball, the positions of
P1, P2, P3 and P4 are:

P1 is at x-1,y+1
P2 is at x-1,y-1
P3 is at x+1,y-1
P4 is at x+1,y+1

    We can now check the background colour under these four points with the
POINT command as shown in lines 200 and 210. Testing each point in turn will
give us a value which represents the angle of the obstacle. This is where the
array B(4,4) is used.

    The following table allows us to cross-reference the value obtained above
with the original direction to find which way the ball should bounce.

                     original direction
              left(1)   up(2)   right(3)   down(4)
         1      2        0         0          3
obtained 2      4        3         0          0
value    3      0        1         4          0
         4      0        0         2          1

Table I: Cross referencing the obtained value with the original direction.

    For example, if the obtained value was 2 this indicates the ball has hit a
type-2 obstacle - shown in Figure III.

STOSPIC.PC1:<<SCREENSHOT>>

    There are only two possible directions the ball could have been travelling
in to hit this type, namely left or up. If it was moving left, the table now
shows that the resulting direction will be downwards. On the other hand, if it
was moving up it will now start to move right.

    If you're still confused, which wouldn't be all that surprising since this
concept can be difficult until you get used to it, try comparing Table I with
the array in lines 60 and 70.

    You should now be able to see how the program works and understand the
principle of using points around the centre position to determine the new
direction. Next month I'll take these concepts further and get the ball to
bounce in eight instead of four directions.



=========================================================================
                               HINTS AND TIPS
=========================================================================

    This month I'll clear up a small point which seems to be giving several
readers a few problems. When using the COMPACT.ACB accessory to pack a screen,
a message is displayed indicating that the compacted screen is to be used in
bank 5. In fact, once it has been saved, you can load it into any of the
available banks with the command:

LOAD "filename.mbk",bank-number

    The reason the message states bank 5, is that this is one normally used to
store packed screen data and it's the bank that COMPACT.ACB uses. There is no
reason why you cannot use any of the others to store your compacted screens.


HARDWARE: ALL STs, COLOUR ONLY