M/C Part 10

Smooth sprite movement. Well, there are two ways we can use.

The first is the faster, and the one used in both Triltex and
the Viking Game. Basically, we do a HALT before scanning the
keyboard and joystick. If there's a movement, wipe the sprite
from the screen, and print it at its new location. When we have
a patterned background to mask the sprite onto, whatever we
over-write is copied to a buffer, and this is dumped back to
the sreen to erase the sprite. This method has three main
advantages:

a) The code is nice and simple.
b) The routine is fast because it only updates part of the
   screen.
c) Because we use HALTs, the whole thing is syncronised and the
   sprite moves at a steady speed.

Now, if you recall the last few articles about interupts, you'll
remember that HALT just waits for the next maskable interupt, of
which there are five types - it doesn't distinguish between
them. Now, you can either disable the line interupt (output 255
to port 249) and hope only the frame interupt will need
servicing, or you can disperse with th use of one HALT
instruction, and set up routines to HALT for specific interupts.

If we run the sprite routine off the frame interupt, we can
update the sprite during the frame fly-back. ie, between two
updates of the actual TV screen. This avoids flicker. However,
if we've got a long interupt, taking a long time (eg. playing
music, scanning mouse, etc), the new screen could be updating
before we're ready to dump our sprite, and flicker now results.
This was the case in Triltex, with Frantisek Fuka's music taking
a fair amount of time to play every frame. So, I ran everything
off a line interupt instead.

Firstly, we set up a line interupt just below the game playing
area, and put the music etc inside it. The routine sets a flag,
line_int_on, and returns. If we are at a part of the game moving
the sprite, and to slow it down, we put a HALT in, but to make
sure we are waiting for the line interupt, we change this to

                CALL halt_line_int
                .
                .
                .

We then have a routine,

halt_line_int   push af
hli_loop        ld   a,(line_int_on)
                and  a
                jr   z,hli_loop
                xor  a
                ld   (line_int_on),a
                pop  af
                ret

And hey presto!

Now, this method of sprite movement has its drawbacks. We can
only update one or two sprites during the frame flyback, and it
doesn't allow for background changes. eg, scrolling.
To overcome this, we use a different method, where we have two
screens - the one in vmpr, and a dummy. One by one, the graphics
are dumped to the dummy screen. When it's ready the screens are
switched and the dummy becomes visible. To avoid flicker and
sheer, we must switch the screens after the games playing area
has been updated on the TV, either through the frame or a line
interupt. This does allow for scrolling and more sprite
movement, but uses more memory, and more importantly, more time.