🚀 go-pugleaf

In article <11196@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes:
>	There is indeed some confusion, and it is on your part.

Perhaps. I don't think you've made it clear why, as yet.

>An {odd|even} scan-line frame is a half-frame.

Fine, let's call it that.

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

Then the Flicker Fixer design is flawed. I believe, however, that objects
could still 'come apart' if they are moved every time a half-frame rolls
around. Their movement would have to be synchronized to the full-frame
intervals (i.e. every 1/30 of a second) in order to avoid this.

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

Consider that it clearly knows which is the even half-frame and which is
the odd half-frame in order to fuse them into a full-frame in the first
place (if it got it wrong then it would end up swapping adjacent lines in
the full-frame).

[ This is me he's quoting here: ]
>=-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?

In the terminology you suggested, it needs to buffer two HALF-frames (an
even scan line frame plus an odd scan line frame). My point about motion
pictures says it all if you think about it in more detail...the only reason
that NTSC flickers is because the even scan lines are displayed at 30hz,
as are the odd scan lines. If you "double-shutter" them, as they do with
films, to get a 60hz flicker rate, then the human eye will not see any
flicker.

To be more explicit, you could fix flicker by doing the following:
	- get a half-frame of video from the Amiga (say the even lines)
	- display it twice in the 1/30th of a second before the next
	  half-frame (the odd lines) comes in.
	- repeat on this next half-frame (now we're doing odd lines)
This gives 120hz interlaced, causing a 60hz flicker rate, above the
40hz "critical flicker fusion rate", which perceptually eliminates flicker.

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

That *sounds* similar to what I said...but you still get frames out of
this setup. I guess I didn't explain carefully enough the logic in my
conclusion. We agree that we want to be able to display arbitrary
pieces of RAM just by setting a base register. But this means that
when that base register is changed, suddenly the entire screen is updated
from the new RAM area. That gives you a frame, in the sense of the
screen being updated over discrete rather than continuous time intervals.
Maybe you meant just "interlaced frames"??? In which case--sure, I agree,
why have *interlaced* frames at all.

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

Thanks for the correction.

>=-> Come to think
>=->of it, why bother with pixels at all?
>=-This *sounds* good, but obviously in practice it'll have finite limits.
>=-Even holographic film is not truly continuous, it has "pixels" (grains)
>	Yes, yes, NOTHING is truly continuous on an arbitrarily small scale.

Then what *did* you mean???

>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
>be bounded from below by physical constraints.  That doesn't mean the programmer
>has to explicitly 'color' every one of these tiniest points.

Ok, fine. Then let me try again. You suggest avoiding pixels altogether.
Since you didn't like my analysis of why that is a meaningless suggestion,
the burden of proof falls on you. Explain exactly what this would mean.

>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 
But, but...I *did* try out that definition, when I said "continuous
positioning but a finite number of points to be drawn". I still have
a problem with phrasing "points to be drawn", because to me that means
pixels. Maybe not to you?

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

I guess this means my posting came across rudely. Sorry about that.
As for the pedagogical style, I was just trying to be thorough. Since
we're not on the same wavelength yet, I failed in my purpose. Nonetheless
I think pedagogy is preferable to flames when people disagree on the
net; do you agree?

>_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___

Agree; Let's both try and follow this advice.

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