🚀 go-pugleaf

Bill Moyer (ttk@rahul.net) wrote:
: In article <3vbpdk$i4b@noc2.drexel.edu>,
: James Ianni <sg928ah5@dunx1.ocs.drexel.edu> wrote:
: >Bill Moyer (ttk@rahul.net) wrote:
: >:   You haven't been using Sprites with your PC?  I'm sorry.  If you like,
: >: I can email you some software that allows you to use full-length, multi-
: >: colored Sprites on your IBM.  They're written for use under DOS, but I've
: >: been using them under OS/2's DOS sessions with no problems and no slowdown.
: >
: >: -- ttk@rahul.net
: >: -- 
: >: Bill Moyer <ttk@rahul.net>
: >
: >Sprites *HAVE TO BE* supported in hardware, if the hardware ain't got it,
: >then you have no sprites. IT'S IMPOSSIBLE TO DO SOFTWARE emulation of
: >SPRITES. Well, actually it doesn't make sense.....
: >The only sprites I remembered that *SOME* graphics crads supported were
: >just a cursor/pointer, ie 1 MONOCOLOR SPRITE THE SIZE OF A PEE!!!
: >Come on Bill get real...

:   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 [..]"?
: -- 
: Bill Moyer <ttk@rahul.net>

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.
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!