Hello Paul, I've been hanging around in here but haven't considered
myself worthy of replying until now. I may be able to shed a little
light on the video tricks that you have described although I'm only
experienced through trial and error and am open to criticism.

PE>Actually, also while I'm here, I want the screen saver to draw some fish on
  >the screen, swimming around.  Am I correct in assuming I am
  >meant to produce about 3 icons of the one fish, with
  >various orientations, and then just iterate through them?
  >Also, will I need to continually repaint the screen or
  >what?  Just how does this get handled?

Yes you draw as many graphic images as you require for the animation
eg a[0] = ( , a[1] = _ , a[2] = ).

One way of doing a screen saver onto a zeroed screen is to xor the
graphic data to screen memory twice. Once to turn it on and the other
to turn it off before you turn on the next image etc.

Of course if you have background data this does not work and the real
trick is to set up a virtual screen areas large enough to support your
image  *vs1 = malloc(imagewidth*imagehieght)

step 1 copy screen data where image is to go to vs1
     2 copy a[i] to screen              // i=image number
     3 copy vs1 to screen   = Background back on screen erasing image
    inc movement;
    inc i;
step 4 copy new screen data where image is to go to vs1
     2 copy a[i] to screen              // i=image number
     3 copy vs1 to screen   = Background back on screen etc.
etc. etc.

PE>It has always been a great mystery to me how people can possibly write arcade
  >games, e.g. Space Invaders.  I would have thought that when
  >the bullets blasted the shield, you virtually needed
  >artificial intelligence to draw the result.  Also, knowing
  >that a bullet has hit a target, when there's so many
  >bullets and so many targets.  I would have thought we would
  >have had a situation a bit like the travelling salesman
  >problem.  And travelling over the background, needing to
  >redraw that again?  I would have thought that it would take
  >so long to do all this, that the arcade games would have
  >become batch jobs.  Instead of this, people manage to write
  >them in about 10k of object code (on the Commodore 64
  >anyway), and they are as good as the arcade parlour.  What
  >is the secret?  Thanks + bye.

On the 64 the secret was hardware sprites and Raster interupts however
on the PC it is not so easy and I doubt your 10k would bare fruit.
As far as bullets are concerned the hardware data handled collisions
of two sprites so that was no problem, however the PC programmer really
need only check the co-ords of the victim in relation to any moving
object and if equal then he is DEAD. Generally the actual movement is
interupt driven and a flag is set if the x of the bullet = the x of
the victim, same for y... The programmer need then only check and
reset the flag during each cycle.

I think however that what you are really asking is how can so much
animation appear on such a static display.

If you are, then the general answer is dual play fields which comprise
a virtual screen for each dimension of the visual screen. This means
that each dimension of the visual screen is positioned on its own
virtual screen and the virtual screens are then overlayed onto the
main Virtual Screen before being transfered to the visual screen.

This is similar I imagine to how you would redisplay your windows when
they overlap in Dos, OS2, etc with top priority given to the active
window which would overlay last and appear in the foreground.

A I said earlier Paul, I'm no expert especially on this PC, however I
have found that many of the 64/amiga principles can be utilized fairly
well if we make use of the PC's power and speed.

Hope this helps anyway or at least it opens up a discussion I'm
capable of entering...:-)

(OH! WELL!  Life's like that Sumtimes.)  Regards Ron T Lewis

 * OLX 2.1 TD * Reality is only for those who lack IMAGINATION..

--- Maximus/2 2.01wb