Path: utzoo!attcan!uunet!jarthur!bridge2!mips!sgi!shinobu!odin!icon!naegle
From: naegle@icon.SGI.COM (David Naegle)
Newsgroups: comp.graphics
Subject: Re: Animation Speed
Message-ID: <8763@odin.corp.sgi.com>
Date: 8 Jun 90 21:21:38 GMT
References: <675.266fc62b@waikato.ac.nz>
Sender: news@odin.corp.sgi.com
Reply-To: naegle@icon.SGI.COM (David Naegle)
Organization: Silicon Graphics Inc.
Lines: 41

In article <675.266fc62b@waikato.ac.nz>, math1205@waikato.ac.nz writes:
> I have been experimenting with sprite animation recently and came up
> with an unexpected result which I can not explain.
> I'm using an Atari ST with a 50Hz colour monitor to animate a sprite 
> moving back and forth across the screen. The program was a simple loop 
> which did the following:
> 
> Drawsprite(x,y)  VerticalSync()  Undrawsprite() Update_Pos(x)
> 
> The sprite used was a small 8x8 pixel ball and the x-increment used is
> 16 pixels. This version worked nicely and gave a very smoothly moving ball 
> displayed at a refresh rate of 50Hz.
> 
> The next version should also display a smoothly moving ball which is
refreshed
> at the slower rate of 25Hz via:
> 
> Drawsprite(x,y) VerticalSync() VerticalSync() Undrawsprite() Update_Pos(x)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not an Atari programmer, but I have seen this problem, too.  You are
really displaying the image twice, and then updating the position. 
Refreshing is still taking place at 50Hz.  The human visual system is
capable of tracking and interpreting motion at rates well above our
average response time to discrete events.  We actually anticipate where
a moving edge will be in the next frame. In the case you discribe, the
sprite appears to be instantly stopping and starting at 25Hz.  This
confuses your visual system:  Real objects posess
inertia, and don't move in discrete jumps.  However, *two* objects, displaced
by the difference in their positions in successive frames, is a
perfectly reasonable interpretation to place on the stimulus you are
presenting to it.

This is a classic example of what can happen when you trick your 'tiger
detector'.  The effect seems to disappear at update rates slow enough to be
perceived as discrete events (jerky animation).  Another way to deal with
the problem is to compute 1/25Hz worth of 'motion blur' for the image.  Or,
just live with it.  You are not making any easy-to-fix mistakes.  And your
animation class was not wrong, either.  After all, look how smoothly the
*two* sprites appear to move. :-)  

Hope this helps.