math1205@waikato.ac.nz (06/08/90)
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 seemed to recall from computer graphics literature that a refresh rate of 20 Hz should be sufficient to give the impression of animation. What I actually saw was two very faint balls adjacent to each other travelling across the screen. Even when the x-increment is reduced to 1 pixel the same effect is noticeable as a blurring of the image. Is the reason for this ghosting effect a too slow refresh rate? And if so, what is the minimum refresh rate to produce smooth animation? Replies please ! Wayne Schou MATH1205@waikato.ac.nz
naegle@icon.SGI.COM (David Naegle) (06/09/90)
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.
dave@imax.com (Dave Martindale) (06/09/90)
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. > >Drawsprite(x,y) VerticalSync() Undrawsprite() Update_Pos(x) > >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) > >What I actually saw was two very faint balls adjacent to each other >travelling across the screen. > >Is the reason for this ghosting effect a too slow refresh rate? And if so, >what is the minimum refresh rate to produce smooth animation? This double-image effect is due to the fact that the CRT is displaying each image twice. The ball is shown at position 1 for 2 screen-refresh periods, then at position 2 twice, then at position 3 twice, and so on. Your eye follows the motion of the average position of the ball, and sees the individual images as being either ahead or behind this average position. For example, assume that the ball moves 16 pixel every 1/25th of a second. To follow it, your eye moves at the same rate, or 8 pixels every screen refresh. Thus when each frame is drawn for the second time, your eye's field of vision has moved 8 pixels, and the ball appears to be offset 8 pixels from the image produced from the first screen image. If you held the same image on screen for 3 vertical sync periods, you would see a triple image of the ball, with each of the ghost images separated by 1/3 the distance that the ball actually moves between updates. This effect is common to any system that shows an identical image more than once, such as film projectors running at 24 or 25 fps. It may be more obvious in your computer-generated image because there is no motion blur, but movies do suffer from it too. Running film cameras and projectors at 48 fps or faster would eliminate the double image, at a cost of twice as much film. 24/25 fps is a compromise that works well enough most of the time. Images from a TV camera do *not* have the problem, since they consist of 50 or 60 different fields per second.