🚀 go-pugleaf

In article <1992Dec19.221442.3741@news2.cis.umn.edu> toddl@county.lmt.mn.org (Todd Lehman) writes:
>In article <1992Dec19.190258.15117@midway.uchicago.edu> greg@dent.uchicago.edu (Greg Kuperberg) writes:
>>15 or more frames per second looks good, and it is a waste of CPU
>>time to have more than 30 redraws per second.
>For 3D animation, sure...maybe the animation rate doesn't matter that much.
>
>But for sprite-type animation, the animation rate actually DOES matter. 
>If you move an object at 30 f.p.s. on a monitor refreshing at 60 Hz., there
>will be a double-image effect, and the animation will appear jerky.

My comment about >30 redraws per second was an overstatement and you
have a very good point about synchronizing animation with monitor refresh.
It has nothing to do with whether or not the animation is 3D, except
that 3D animation can be so hard that many other niceties besides
synchronization with the monitor go out the window.

What you are talking about it is what is known in film computer
graphics as the strobe effect.  The film people can't solve the problem
by changing the frame rate, for obvious reasons.  Instead they
introduce motion blur, whereby a single frame is a composite image of
many instances in time.  Moreover, avoiding the strobe effect
by increasing the frame rate can be added to the brute-force hall of
fame alongside anti-aliasing by means of higher resolution and
memory management by means of large computer memory.

However, very few if any personal game or computer platforms have the
CPU time available to compute complex motion blur.

Sticking to the more basic issue of diminishing the kind of strobe
effect that you mention as well as its crude cousin, flicker, the ideal
is to never let the monitor send an unwanted pixel to the phosphorus,
as well as never to waste time drawing pixels that won't be displayed
anyway.  If your monitor refreshes the even lines in a 60th of a second
and the odd lines in the next 60th of a second, then you will be a Jedi
Knight among animators if you redraw the even lines while the monitor
sends the odd lines to the phosphorus and vice-versa.  In theory
you will save CPU time and gain smooth motion.

Perfectionist though I was when I wrote games, I never synchronized
my games with the vertical retrace.  I was content with avoiding
flicker by not letting the monitor display an erased sprite that hadn't
been redrawn, and my IBM games were timed to the system clock, which
is hopelessly out of synch with the vertical retrace.