Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!TIS.COM!dmb
From: dmb@TIS.COM (David M. Baggett)
Newsgroups: comp.sys.atari.st
Subject: Animation Topics
Message-ID: <8809100453.AA01878@TIS.COM>
Date: 10 Sep 88 04:53:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 51


   There has been a bit of talk about animation here lately; here's my
two cent's worth:

Sprite Speed Limit
------------------
   Robert White asked about the time it takes to smoothly move a sprite
across the screen.
   Since the vertical refresh only occurs every 1/60th of a second, it will
indeeed take about 6 seconds for a sprite to move across the screen if you
move it one pixel per page flip.
   However, moving the sprite more pixels per refresh does not change the
smoothness of the animation as much as you might think.  The sprites in 
HacMan (a public domain game available at an archive near you :-) ) move
between 2 and 8 pixels per page flip.  The animation doesn't appear
jerky until about 5 pixels per page flip (Board 19, "Chris Vs. HacMan", has
the sprites moving at 4 pixels per page flip).
   Also, the page flips in HacMan do not even occur every 60th of a second;
they occur every 30th of a second (the program misses every other vblank),
and the animation is still satisfactory.
   The blurring effect you get when you move a sprite, say, 2 pixels every
60th of second is not flicker, it's strobing.  It's just that the new image
appears before the old image has completely faded from the screen.  This is
really obvious on IBM monochrome monitors, but only slightly evident on
the ST RGB monitor.

Implementing the Page Flipping
------------------------------
   It is true that you can change the screen pointer "by hand" by changing
a location in page 4.  Unfortunately this doesn't produce very nice
results (Setscreen works better than any hack I've seen).
   Setscreen doesn't cause any delay at all.  The call returns immediately.
However, if you change the physical screen base with Setscreen, the change
won't _take effect_ until the next vertical blank.  In other words, the
code to actually set the physcial screen base is in the vertical blank
interrupt code (along with code to set the palette and the "media changed"
flag code, etc.)  Thus, two succesive calls to Setscreen will frequently
only have the effect of the last call (unless a vertical blank happens to
occur between them).
   So, you have to explcitly wait for the vertical blank after you call
Setscreen to be sure that the new physical base got set.  E.g., 

	Setscreen((char *) -1L, (char *) new_phys_base, -1);
	Vsync();

   Anyone interested in animation should check out the Animatic demo in
the archives!  (Sorry, I just couldn't resist the temptation to 
advertise) :-)

			Hope this is useful...
			Dave