Path: utzoo!mnetor!uunet!husc6!bbn!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: <8889@agate.BERKELEY.EDU>
Date: 18 Apr 88 20:29:31 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <5735@well.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: doug@eris.UUCP (Doug Merritt)
Organization: University of California, Berkeley
Lines: 29
Keywords: Fixin' a flick

In article <5735@well.UUCP> aleks@well.UUCP (Brian J. Witt) writes:
>In article <8557@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes:
>> Presumably you could
>>do this by sending the display a set of simultaneous differential
>>equations which it would then display as continuous curves/surfaces.
> 
>     I know it's not the thread, but the thread is enjoyable!
>   It's a lot better than programming language wars =(:-|).  

Thanks!

>   BTW: if you animate 30 frames/second, what keeps you from changing
>   the image on the other-every frame the fF does grab.

You could conceivably write software especially for the purpose of
hiding this design problem with fF. I doubt this would be desirable...
since fF always combines adjacent fields, it's hard to think of a
nice way to work around this that is any better than either a vanilla
fF effect, or than a vanilla interlace with no fF. In other words, you'd
have to sacrifice *something*, whether it's the effective frame rate,
or slowing down object motion considerably, etc.

But in any case, there's nothing to be done about the problems it will
have with *existing* software.

Caveat emptor.

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