Evil Dead's Falcon Programming Tricks

 "A  marvelous creature.  A model of specialization...  Who  else
could suck an ant up his nose and enjoy it?"
                     About anteaters, "B.C." strip by Johnny Hart

              SOME FALCON PROGRAMMING TIPS & TRICKS
                          by Evil Dead

 This  article  should  originally  have  been  released  in  the
previous  issue of ST NEWS,  but in the end there  wasn't  enough
room  for the source material to be included with it.  So now  it
is,  finally, so some of you people may finally get introduced to
demo coding on the Falcon.

True colour 32x32 sprites

  Here I explain how to code 32x32 sprites in 320x200 true  color
mode.  The sprites are masked and each sprite could have its  own
coordinates.  I've coded it in a way that it works on both SVGA &
RGB modes.
 I  think the Falcon is too slow for its hardware;  it  has  true
colour  video  capabilities and full stereo 16 bit sound  with  a
main  processor  based on a pseudo 32 bit  processor  running  at
16Mhz  with  512  bytes total cache.  If you look  at  the  other
platforms you'll notice that all machines with simillar specs are
equiped with at least a 32 bit 32Mhz processor. When trying to do
some  real graphic movement you'll notice that the 16  Mhz  32/16
bit processor of the Falcon is really too slow...
 I've  noticed that the Falcon is basically too slow  to  display
many  sprites;  I  can  get only about  6  sprites  (with  screen
switching),  but  if  I optimize the code there should  be  more.
Using the DSP chip with this code will not decrease the CPU  time
here, because there isn't mucht to calculate. In this version the
sprite underground will be saved and restored so that the sprites
can be drawn on a picture or something like that.

 Basic principles:

 You have to restore all screen data first before saving the  new
sprite data.
 You could do this with multiple 'movem' instructions in a 'dbra'
loop  (I think this is the fastest way).  The  restore  positions
should be saved while calculating the screen offsets when  saving
the sprites.  Saving sprites is nothing else then reading  screen
data and throwing it into a buffer...  Drawing the sprite data is
more  complex since you must mask the sprite data with  the  data
already on screen,  but in true colour (where each pixel has  its
own data word) this is no big deal (only data must been drawn, so
the only thing to do is skip empty data (black).  A simple way to
do this is:

nextpix:
        move    (a0)+,d0        * fetch sprite dataword (1 pixel)
        beq.b   nodraw          * if empty (d0=0) skip drawing
        move    d0,(a1)         * draw pixel on screen
nodraw:
        addq.l  #2,a1           * update screen pointer
        dbra    d7,nextpix      * repeat drawing

 In this version I made a simple sinus table which is based on an
old ST resolution (where I multiplied all Y coordinates with  160
for fast calculating). In true colour 320x200 mode every scanline
is 640 bytes and where 640/160=4 I only have to shift left the  Y
position  2  times (which is much faster than multiplying  the  Y
position  by 640!).  The X position should be shifted  left  once
(since one pixel horizontally is one word screen data).  A simple
screen offset routine looks like this:

        * d0=xpos
        * d1=ypos (multiplied with 160)

        lsl     #1,d0   * multiply x with 2
        lsl     #2,d1   * multiply y with 4 (y=(y*160)*4)
        add.l   d0,d1   * add x+y
        add.l   d1,a1   * add to screen base

 Now you have your screen address.

 A  simple way to manage sprite position resetting  and  multiple
sprite  pointers is to declare an array with an equal ammount  of
elements as sprites:

posits:
r       set     0
        rept    numspr
        dc.l    sinus+r,sinus+r         *(where the first long is
                                                       the actual
r       set     r+300                   *position and the second
                                                   the reset pos)
        endr

 When  you  calculate  the  screen address  you  must  check  the
pointers for resetting The most simple way to do this is:

        lea     posits(pc),a1
doagain:
        move.l  (a1),a0
        move    (a0)+,d0
        move    (a0)+,d1
        bpl.b   notreset
        move.l  4(a1),(a1)
        bra.b   doagain
notreset:
        ...

 Screen  switching on the Falcon is not more complicated than  on
standard  STs.  The  Falcon has 3 video address  registers  which
makes  it more simple to set a screen anywhere.  I made a  simple
routine  which  allows  you  to code  most  routines  (which  run
normally  on 1 screen) on two screens.  You only need to  declare
two screens and a few instructions at the start of the VBL:

VBL:
        movem.l d0-a6,-(a7)
        tst     which(pc)
        beq.b   screen1set
        move.l  screen2(pc),d0
        move.l  screen1(pc),screen
        move.l  screen(pc),screen2
        move.l  d0,screen1
        bra.b   go
screen1set:
        move.l  screen1(pc),d0
        move.l  screen2(pc),screen1
        move.l  d0,screen2
go:
        move.b  d0,d1
        extb.l  d1
        lsr     #8,d0
        move.b  d1,$ffff820d.w
        move.l  d0,$ffff8200.w
        eori    #1,which
        .
        .
        .

 If  you  do  screen switching like this you don't  need  to  use
absolute addresses.

 I  think this code is far from perfect but since it  is  nothing
more than a spare time project I don't care...
 I  hope  that I can make some more articles in the  near  future
about the ups and downs on the Falcon.

 If you want to contact me:

 *** EVIL DEAD ***
 Reinwardtstraat 132
 NL-2522 AG  Den Haag
 The Netherlands
 Tel: ++31-70-3990535

 I  Hope  this source will help you to develop the  most  amazing
demos ever :-)

                  Greetings from * Evil Dead *