🚀 go-pugleaf

In article <1992Dec20.214910.24668@cs.uoregon.edu> mkelly@mystix.cs.uoregon.edu (Michael A. Kelly) writes:
>>Very few if any personal game or computer platforms have the
>>CPU time available to compute complex motion blur.
>
>Right.  If they did, they could just increase the frame rate.

Yes, although having more animation frames than vertical retraces truly
is a waste and the strobe effect might still be there.

>How can I reduce or eliminate the effect, without increasing the frame
>rate, on a non-interlaced monitor?

What you must first do is make absolutely sure that you have no extraneous
causes of jerky motion or flicker.  If you have other timing or
graphics problems in your animation, reducing the strobe effect will
not only be a waste of time, but also you will not recognize successful
motion blur when you achieve it.  Extraneous causes include but are not
limited to:

o You think your animation frames are in synch with vertical retrace
but they aren't.
o Sprites are sent to the phosphorus before you are done drawing them
into your video RAM or while you are erasing them.
o In some types of clocked animation, a redraw that takes 1.05
animation frames to complete will be followed by a wait for the next
clock tick, so that the frame uses 2 entire clock ticks.
o In a multitasked or interrupt-driven environment, some other task
may be stealing your CPU time.

All those other potential pitfalls aside, it is possible to incorporate
simple motion blur without too much extra work.  A given frame on the
screen is really a composite of many instances in time, and what you
should draw is the average of the desired images at all those times.

Say that you want to motion blur a moving airplane
sprite and you know that 99% of the time the airplane is flying over
a constant-color field and does not meet any other object.
Say that the airplane moves four pixels in one frame.  Then you can
make a sprite which is the average of the airplane at all four
positions.  In other words, if the airplane sprite is realized
by three intensity tables RAirplane[x][y], GAirplane[x][y], and
BAirplane[x][y], then you make a new sprite like this:

RAirplaneAvg[x][y] = (RAirplane[x][y]+RAirplane[x+1][y]+
                      RAirplane[x+2][y]+RAirplane[x+3][y])/4;

GAirplaneAvg... etc.

You don't have to average in images that are a single pixel apart
if your sprites move a large number of pixels per frame; it can
suffice to take steps of n pixels for some other n.

You must remember to always take the average of the same number of
color values in a given blurred sprite.  If you step outside the
sprite's mask or rectangle you use the background color instead; don't
take an average of a smaller number of values.  If your background is
is not constant color to approximation you should ideally have 
a separate blurred sprite for each possible offset relative to the
background pattern.  If your background doesn't even repeat the
trick of making blurred sprites just doesn't work.  You must blur
the images some other way.

If your system, like most personal computers, uses a color look-up table
rather than intensity scales, you must convert to intensities, average,
and then find the closest colors in your table.

But the main point is, it isn't just a hack, it's right.  Perception of
motion IS motion blur IS averaging of images.  An averaged animation
image is a mathematically sound approximation to what your eye really
wants to see.  The only way that it's not right is that a weighted
average of images may be closer to the ideal than the flat average
mentioned above.