Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!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: <8693@agate.BERKELEY.EDU>
Date: 13 Apr 88 20:29:24 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <8649@agate.BERKELEY.EDU> <11227@ut-sally.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: doug@eris.berkeley.edu (Doug Merritt)
Organization: University of California, Berkeley
Lines: 57

In article <11227@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes:
>In article <8649@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes:
>=-time (in 1/120 sec):    0  1  2  3  4  5  6  7  8  9 10 11 12
>=-time (in 1/60 sec):     0     1     2     3     4     5     6
>=-time (in 1/30 sec):     0           1           2           3
>=-half-frame displayed:      ...      1  2  1  2  3  4  3  4  etc
>=-full-frame displayed:      ...      1  1  1  1  2  2  2  2  etc
>=-This shows a full-frame being generated and displayed each 30th of
>=-a second. But each half-frame is displayed twice within that interval
>=-(e.g. half-frame number two appears twice in the first 30th sec).
>
>STILL have to buffer four fields to prevent breakup.  Therefore, all this might

Huh? You lost me...in the above diagram, first fields #1 and #2 are buffered,
and then fields #3 and #4...that's only *two* at a time. Where did "four"
come from? Hmmm...do you mean in terms of memory requirements? It's
true that you have to capture 3 & 4 while displaying 1 & 2, that's four
frames, for sure. But it sounded like you were talking about something else.

BTW I eventually come to realize that this 120 hz scheme is overkill,
based on your comments, but first a few other issues:
 
>=-The second-order effect is smoothness of motion. [ ... ]
>	Now you're on track.  Your method would be smoother.  [ ... ]
>is only 33% more jumpy than 'real motion,' assuming a linear relationship,
>whereas un-double-shuttered film is 67% more jumpy.  Your method shows each
>field for 1/120th second, which is 200% LESS jumpy than reality (no

That would be nice, wouldn't it? Unfortunately, it requires intermediate
*generated* frames as well as *displayed* frames, to show the intermediate
positions of moving objects, to smooth *motion*. The Amiga can't really
generate them, because it can only send out fields at 60hz (and frames
at 30hz of course). On the other hand, it's feasible (though difficult)
to *interpolate* those frames. See work done by the "Advanced Television"
research group at the MIT Media Lab; the perceptual smoothing of jerky
motion is quite noticeable.

So again, all this fancy 120hz scheme (without motion interpoloation)
does is eliminate *stroboscopic* flicker, not *motion* jerkiness. It'll
look *exactly* like the Amiga's current interlaced display, but with no
flicker whatsoever.

>This seems a little excessive, if the cost of
>a 120Hz display is going to be about twice that of a 60Hz display, which is a
>reasonable assumption.

*At least* twice as expensive, yes. Plus quite a bit of extra cost
if one adds real-time motion interpolation hardware! So yeah, it's
excessive in terms of cost. But it would look real nice!

Of course, your analysis points out that all this is overkill,
without motion interpolation, because if the flickerFixer did things
"right", it too would look just like the Amiga's interlaced display,
only without flicker. And it would only need a 60hz frame rate to do so.

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