Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!pasteur!agate!eris!doug
From: doug@eris (Doug Merritt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <8712@agate.BERKELEY.EDU>
Date: 14 Apr 88 01:33:51 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <3626@cbmvax.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: doug@eris.berkeley.edu (Doug Merritt)
Organization: University of California, Berkeley
Lines: 110
Summary: I thought we covered this already...

In article <3626@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes:
>I just thought I'd throw some idle thoughts into the fray.

Hedley, I'm sorry, but you've gone off half-cocked with these
idle thoughts, and you're only going to confuse people with this
misinformation.

>The FlickerFixer design is not flawed given the boundary values of the
>problem.  [...] Given this constraint, its about the highest degree of
>functionality you can get.

Incorrect. The software may *already* be synched to a 30hz display
rate (in a sense, this is the smart thing to do even with 400 line
interlaced Amiga animation). In which case the fF is mixing together
the old frame with the new frame, which is incorrect, as it defeats
the whole purpose of double buffering.

You are correct only in the case where the software is synching its
double buffering to a 60hz display rate. Which it should not, in general,
because that'd screw up double buffering of interlaced images. So
fF wins only when the software loses!

Unless it is specifically taking advantage of the interlaced display to show
twice as many frames of a moving object for smoothing, which I haven't
noticed anyone doing, and which would not work well with any kind of flicker
fixer anyway, for self-evident reasons.

>	You do not need to buffer 400 lines of information for a 60hz
>flicker fixer. You only need half the full screen and a couple of lines.

Given the assumption you made above about fF being designed right,
this would be correct. But given my rebuttal above, it's incorrect.

You *do* need 400 lines (plus a couple) for "correct" 60hz flicker
fixing.  You need to merge the two fields and display them once (you could get
away with 200 lines just for this), and then display them both *again*
at the same time you're using the extra couple lines to begin grabbing
the start of the next field.

The reason is that, by the time you need to display the whole frame the
*second* time, the original two fields are gone and you're moving on to
grabbing the *next* two fields. This means you can't simply mix in the
second of the fields with the first as you get it.

>	Film is indeed 24 frames per second. But the image is shown
>three times, not two. The purpose here is to ( in my mind anyway ) to
>eliminate flicker. If you really wanted to emulate film quality, you
>would probably update the display at only 24 Hz, but refresh the image 
>much faster ( like maybe 72 Hz ).

I know it's fun to throw out random arguments, but I'm afraid that the
15th edition Encyclopedia Britannica disagrees with you. It's double
shuttered...each frame is displayed twice, not three times. See
"Motion Pictures, Technology of". The section on Television mentions
the same fact. And of *course* the purpose is to eliminate flicker; that
is the only reason they bother to double-shutter.

Edison's projector ran at 46 frames per second. Multi-shuttering was
introduced in 1895 purely to allow a savings of film by dropping the
recording rate to 15 to 18 frames per second.

They *did* do triple-shuttering back then, maybe that's what you're thinking of.

Furthermore, triple-shuttering to achieve a 72hz strobe rate is wholly
unnecessary, whether on film or computer display...the double-shuttering
gives you 48hz, which is above the critical flicker fusion rate. Higher
shuttering rates will not produce any perceptable change in quality.
(Although as I discussed previously, having more *real* frames per
second helps smooth *motion* jerkiness. That's not relevent here, though.)

By the way, the reason for the approximate range of values (40-45hz)
for the critical flicker fusion rate (CFFR) is not due to bad recollection,
it's because the CFFR depends on the contrast of the images. Low contrast,
as we all know by now, flickers less. High contrast requires a higher
display rate. Once you get above 45hz you're generally considered safe
even with high contrast.
 
>About 120 Hz displays.
>	Yow ! This would look great, ok. Indeed, you could scroll one
>pixel per frame twice as fast IF you had the CPU/blitter bandwidth to
>do it. ( Arguements about clever bitplane manipulations not withstanding
>due to generality of windowing enviroment ). The point is that you
>really don't have the horsepower to use at this time.

Agreed. Unless you put it into the MotionJerk-Fixer :-) as I suggested by
having (very expensive!) real-time motion interpolation create the
extra 60 frames per second for you.

But I never said that you *could* do this with regular Amiga's.

>	Further, this display type is indeed much more expensive for a
>marginal improvement in perceived display quality.

Very expensive, yes. Marginal improvement, no. It makes, for
instance, smooth scrolling twice as fast, which makes it fast enough
to use for many more purposes than are currently useful. In the same
way it makes any fast moving object look *perceptably* more realistic.
For you to say "marginal improvement" implies an off the cuff judgement
based on no experience with the subject. I recommend that you see the
MIT Media Lab's 1987 Annual Report on video disk if you'd like to see
what a difference this sort of thing can make. (They do *not* specifically
address any particular frame rate in this; you have to read one of
their research papers for specifics...sorry, no references handy. But
it gives a very good intuitive feel for the subject.)

Didn't I already explain most of the above in other postings?
Sigh.

	Doug Merritt		doug@mica.berkeley.edu (ucbvax!mica!doug)
			or	ucbvax!unisoft!certes!doug