Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!gamma!mibte!fmsrl7!eecae!nancy!mailrus!nrl-cmf!ames!husc6!im4u!ut-sally!mothra!bryan
From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <11196@ut-sally.UUCP>
Date: 11 Apr 88 02:28:50 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU>
Sender: news@ut-sally.UUCP
Reply-To: bryan@mothra.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 97
Spam-Content: Negligible

In article <8557@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes:
=-In article <11182@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes:
=->	This imperceptible 120Hz interlace would look exactly the same as the
=->flickerFixer.  The fundamental problem is that the display rate exceeds the
=->screen update rate, so you see the 'half-frame' changes.  What the flickerFixer
=->ought to do is to buffer two frames instead of just one, but this would take 
=->twice the memory.
=-
=-There seems to be some confusion here. It *does* buffer two frames. It
=-takes an odd-scan-line frame, combines it with an even-scan-line-frame,
=-and displays the result twice, resulting in 30 different full frames per
=-second, displayed at 60hz. I'm not an expert about the Flicker Fixer, so
=-I could be wrong about some minor details, but this description certainly is
=-the "right" way to do it. Anything else along these lines but different would
=-be, IMHO, a flawed design. (E.g. if it *always* combined all adjacent frames,
=-not just the two that are "meant" to be paired, resulting in any given
=-frame being displayed first as the fusion with its predecessor, and then
=-as the fusion with its successor.)
=-
	There is indeed some confusion, and it is on your part.  An {odd|even}-
scan-line frame is a half-frame.  The flickerFixer buffers two of these HALF
frames (which I should have said instead of 'one frame'.)  If the fF did what
you suggest , then moving objects would not 'come apart', as I described.  It
DOES always combine all adjacent half-frames.  I agree that it should buffer
two FULL frames, which is what I was pointing out.  However, the Amiga's video
slot might not carry the information necessary to determine which two half-
frames go together, though I find this hard to believe.  Does anyone know?

=-Note that my suggestion was very similar to what's done with motion
=-pictures...there are only 24 unique frames per second. Since 24hz
=-is below the critical flicker fusion point, they double-shutter each
=-frame, displaying it twice, resulting in a 48hz display rate, above
=-the critical flicker fusion point.
=-
	Fine, but how is this relevant?  It still doesn't solve the fundamental
deinterlacing problem.  To do that, you need to buffer two FULL frames.  Who
cares if you then display them at 60Hz noninterlaced, or 120Hz interlaced?
=->
=->	Sure it would be nice to have higher frame rates, but why bother with
=->frames at all?  In the Future (with a capital 'F'), we'll all be looking at
=->8000x8000 solid state displays.  The video display is a stone age relic--it's
=->the only electronic device in common use that still uses a tube.
=-
=-Having frames is not linked just to video technology, it's inherent in
=-the idea of sequentially taking memory out to any display device. The
=-only alternative that would appear to be temporally continuous rather
=-than having discrete frames would be if the imaging device itself were
=-memory mapped (say a non-scanned LCD matrix), so that each pixel were
=-displayed "instantly" upon being written to, with no DMA-like memory
=-transfer happening.  This is possible in theory, but undesirable in practice,
=-because you lose the advantage of having windows larger than the screen,
=-or of "cel animation" by page flipping, or of scrolling by changing a
=-base register, etc.
=-
	Yes, one wants to flip pages and scroll, but this is not linked to
frames.  Think really big:  make all of memory the memory mapped display device,
but only display a portion of it, using x,y base registers.  This gives you
scrolling and page flipping (by scrolling an entire screen width/height in one
step).  Just like a superbitmap window.  Sure it's a complicated memory bit->
pixel interconnection network problem, sure it's incredibly wasteful of 
hardware, but who cares?  This is the Future.
=-> Come to think
=->of it, why bother with pixels at all?
=-
=-Sounds good, but upon reflection it's not clear what this would mean.
=-(In math-speak, one would say that the question is "ill-posed".)
=-
=-You can draw an infinite number of dots within a finite area (note
=-from Calculus this is equivalent to saying you can draw continuous
=-lines rather than points on a finite lattice). 
=-
	In math-speak, a lattice is a partial order in which each pair of
elements has both a least upper bound and a greatest lower bound.  Since we're
being so precise, you'd better stick to 'grid.'

=-This *sounds* good, but obviously in practice it'll have finite limits.
=-Even holographic film is not truly continuous, it has "pixels" (grains)
=-of finite size 

	Yes, yes, NOTHING is truly continuous on an arbitrarily small scale.
Your broad definition of pixels allows you to read all kinds of things into my
short offhand remark that weren't there at all.  If you take the more reasonable
definition of pixels as 'areas of fixed position and size,' then it becomes
obvious what I meant: why divide the display into areas of fixed position and
size for the purpose of drawing into it?  Obviously an the size of an area will 
be bounded from below by physical constraints.  That doesn't mean the programmer
has to explicitly 'color' every one of these tiniest points.
	Assuming a bit of intelligence and knowledge on the part of other
posters would cut down considerably on the amount of pedagogical typing 
necessary on your part.
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|