🚀 go-pugleaf

baylor@ccwf.cc.utexas.edu (Baylor) writes:
>	Say, anyone want to give me a quick explanation of how to do
>sprite animation?

First lets consider a simple form of sprite animation, a mouse cursor.
Here you have just one sprite, and an arbitrary background, and just
one page of display memory.  A simple algorithim would be:

	Turn on sprite:
		- save the background under where sprite will appear
		- copy sprite bitmap to the screen

	Move sprite:
		- erase the sprite by restoring the saved background 
		- save the background under the sprite's new location
		- copy sprite bitmap onto new location

For a mouse cursor this algorithim is typical.  The problem with this
algorithim, as many rec.games.programmer posters have found out is
that it creates a lot of flicker when doing overlapping moves.
This is because for a short time the background is displayed in
the overlapping region.  With mouse cursors this isn't much of a
problem because they're small, and in typical use don't make many
overlapping moves.  In games, however, sprites are often large
and move just one or two pixels at time.

The basic solution to this problem is not to let the user ever
see something on the screen what he shouldn't. (ie. background
in the overlapping region of a sprite move.)  With two video
pages this is simple: while the user looking at one page the
programme is updating the other one to displayed.  When the other
one is ready the programme switches the display to the other page. 
An algorithim for animating one sprite on arbitrary background
with TWO pages would be:

	Turn sprite on:
		- save background under where sprite will appear
		- copy sprite bitmap to undisplayed page
		- switch display pages

	Move sprite:
		- save the background under the sprite's new location
		- copy sprite bitmap onto new location
		- switch display pages
		- erase the sprite from the old page by restoring the
	          saved background for that page

Note you need two buffers to save the background in, one for each page.
An alternative is keep the entire background in a "third" page (doesn't
need to be in video memory), and do the restores from there.

What if you only have one page?  You still can assure that the user
will never see anything he shouldn't but it's a lot more trickier.  
Consider an overlaping sprite move like this:

	AAAAAAAA
	AAAAAAAA
	AAACCCCCBBB
	AAACCCCCBBB
	AAACCCCCBBB
	AAACCCCCBBB
	   BBBBBBBB
	   BBBBBBBB

The A region is where the sprite was and background will appear.
The B region is where background was and the sprite will appear.
The C region is where the sprite was and the sprite will appear.

First you need to update the A region:

	- copy only the A part of the saved background to the screen
	
Now you need to update the C region:

	- copy the C part of the saved background to a temporary buffer
	- copy the C part of the sprite bitmap onto the temporary buffer
	- write the temporary buffer to the screen
	- move the the C part of the saved background from it's part
	  in the saved background relative to the old sprite location
	  to the part relative to the new sprite location.
	  [ confusing, I know...]

Finally update the B region:
	- copy only the B part of the screen to the saved background
	- copy only the B part of the sprite bitmap onto the screen

If your sprites aren't transparent, you don't need the temporary buffer.
If your sprites are large you should try to make sure your sprites are
updated top to bottom.

You can use these same algorithims with multiple sprites, so long
as they never overlap.  If you want overlapping sprites, you need
to do more work.  With two pages it's fairly simple, but with one
page things get much more complex. 

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //