Path: utzoo!mnetor!uunet!cbmvax!hedley
From: hedley@cbmvax.UUCP (Hedley Davis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <3641@cbmvax.UUCP>
Date: 18 Apr 88 04:13:06 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <3626@cbmvax.UUCP> <8712@agate.BERKELEY.EDU>
Reply-To: hedley@cbmvax.UUCP (Hedley Davis)
Organization: Commodore Technology, West Chester, PA
Lines: 215

In article <8712@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes:
=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 rest of you should probably press 'N' now.

=>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.

	Shame on you. I state some premises, and draw a conclusion based
on those premises. You edit the premises out, and then out of context
claim I am incorrect.

	The premises were presuming the case of existent software, and
that NO software changes could be forced.

	Then you cover this by saying the the software MAY already be
synched. What ? MAY already be synched ? This sounds pretty half-cocked
and off the cuff to me. :-).

= 
=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.
= 

I can recall on one program right off the top of my head which takes 
advantage of the 60 hz update in interlaced for motion smoothing. INTUITION.
Curious, one so observant as yourself would miss this. Ever notice that little
sprite pointer thingie ? It's updated 60 times a second.

Did I ever tell you that you have an uncanny method of breaking sentences
into two paragraphs when it lets you end the first paragraph with a punch ?
Read the preceeding two paragraphs again. They basically state that 
in most cases ( No fF present ) 60hz update is correct.

My (edited) statements refer specifically to the microway flicker fixer and
the enviroment it was targeted for, existing Amigas running existing software.

=
=>	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.
=

About that rebuttal:

Paraphasing, you state:

	IF you write software with the knowledge that your interlaced 
	display should only change 30 times a second, AND your scan 
	converter buffers two whole feilds, AND you happen to swap buffers 
	on the correct feild, then you have the ideal solution.

Then you provide the precise arguements as to why no such standard exists.
IE, without a flicker fixer, 60hz double buffering the video looks better
than 30 hz.

Given that most interlaced software is displayed without a scan converter,
by your arguements, it should be updated at 60 hz. Given that the 
microway product cannot repair this, it is designed to the highest degree 
of functionality you can get.

Therefore your allegation that the flicker fixer is incorrectly designed
is incorrect.

=
=	[ Further derivations of theroms based on afformentioned
=	inconsitant logic deleted. ]
=

= 
=>	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. 
=
= [... Interesting comments ( no sarcasm here, I mean it ), deleted .. ]
= 
=They *did* do triple-shuttering back then, maybe that's what you're thinking of.
= 

Ok, I went to the library and checked this out. You are correct.
However, you are way off base here with the 'random arguements' comment.

Typically, silent films run at 16-18 frames per second and are
triple shuttered. Sound films, due to the need for higher film speeds
to support the audio, run at 24 frames per second and are double shuttered.
( This is the thanks I get for taking apart that old projecter in 8th grade. ).

So, the stuff you see in the theater is 24 FPS and flickering at 48 Hz.

=
=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.
=

Well, your arguements are not quite so correct here.

Flicker perception depends not only on contrast, but brightness as well. 
The reason films in theaters do not flicker is that they are shown in a 
darkened enviroment. 

One reference indicated that 'The brightness at the center of the screen 
for veiwing 35 mm. motion pictures should be between 9 and 14 foot lamberts 
when the projector is running and no film is in the gate'.

It went on further to note that some enviroments 'often employ a
very high screen brightness which creates noticable flicker although
shutter frequency is maintained at the required 48 interuptions
per second.'

I go further to note that 50 Hz. CRT displays typically flicker.
By typical, I mean in a well lit enviroment such as an office or workplace. 

So, even though my arguements may be based on 'bad recollection', yours
use references that may have their place in academia, but do not apply
to the enviroment of this discussion, IE computer displays. ( Unless
you use your machine in a dark place ). Computer displays are typically
specified at a screen brightness of 25 FL. 14 F-L is not bright at all,
indeed it is hard to read in a typical office envirment. 

= 
=>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.)
= 
=

	Ok, you can scroll faster. Like maybe twice as many lines per
second. Question:  Do you want to smooth scroll really fast, ( like twice 
as fast ), or see twice as much information on the screen  ( like 400 lines
instead of 200 ) ?

	Unless memory bandwidth suddenly becomes much less expensive than
it is now, doubling the display resolution in spatial or color domains
will take precedence over the temporal domain. You can yell and kick all
you want, but bandwidth is bandwidth, and ( excepting a small number of
specialized uses ), spatial and color bandwidth will take precedence over
temporal bandwidth.

	Recall you are using a 400 lines display where, from the same machine,
you could use a 200 line display ( and expend that bandwidth on the temporal 
domain if you choose ). 

=
=
=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
= 

Hedley