🚀 go-pugleaf

In article <3vmkr3$fh4@noc2.drexel.edu>,
James Ianni <sg928ah5@dunx1.ocs.drexel.edu> wrote:
>Bill Moyer (ttk@rahul.net) wrote:
>:   It's not clear to me why you claim sprites must be implemented in 
>: hardware.  As I said, I've been using software implementations of 
>: sprites for a while now.  I suspect we're dealing with a difference
>: in definitions.  Could you precisely define for me what you believe
>: sprites are?  And my offer to send you the sprite libraries was not
>: an idle one.  Perhaps it would be easiest if I sent you the libraries,
>: and you looked them over and posted something like "This is not a
>: software implementation of sprites because [..]"?

>In a video game, if you used TRUE hardware sprites, you can move that
>sprite about just by changing it's x and y location, that's it.
>For software 'sprites' somewhere in the emulation, you *MUST* first store
>the area or picture underneath the future position of the 'sprite' then you
>*MUST* cut a hole in the bitmap picture then OR the image on the bitmap.
>When the software 'sprite' moves, you *MUST* restore the background and
>repeat the first three steps again. The software sprite *ACTUALLY* exists
>in the picture bitmap while the true hardware sprite id defined elsewhere
>in memory and is overlapped on the picture by hardware, sort of like
>genlocking title credits at the beginning of a movie.

Better method to put the image on screen is to XOR with color map, 
AND with image mask, XOR with color map again. Used to do this on
the Apple ][ all the time. This will cause any area where the mask 
is set to not change and any area where the mask is clear to be 
replaced by the color from the map.

If your window system keeps the 'actual image' off screen, you can
just load from the original image and store to the on-screen area.

If it doesn't, you need to make a copy of the background and be
prepared to roll in new background as the cursor moves. You should
also remove the cursor before allowing screen draws to that area.

>As you can see hardware sprites require 0% CPU usage, and if you add a
>COPPER, you can do really amazing things with sprites. That is why even
>the old 1985 Amiga 1000 can animate dozens and dozens of characters on
>screen while even '486's have some can't do it without some 64-bit
>acceraltor. The Amiga is cheating! 

The hardware approach is nice, especially for cursors and collision
detection. That is why a lot of video games used these methods. 

-Bret
--
------------------------------------------------------------------------------
Bret Indrelee        | ...and if I feel a rage, I won't deny it.
bret@winternet.com   |