Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!petro!swrinde!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: <11204@ut-sally.UUCP> Date: 11 Apr 88 23:49:15 GMT References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <11196@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> Sender: news@ut-sally.UUCP Reply-To: bryan@mothra.cs.utexas.edu Organization: Spam Detection & Removal Squad, Austin, TX Lines: 171 Spam-Content: Approaching critical mass In article <8577@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =-In article <11196@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: =->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. Indeed. =-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). =- Ok, yes, you're right that it has to know which half-frame is even and which is odd, BUT, it still combines all adjacent half-frames, and that's where the 'breakup' comes from. Object motion *IS* synchronized to the 1/30th sec full-frame interval, BUT the flickerFixer doesn't ALWAYS display the two half frames that go together. Perhaps this will help: Display sequence, in increments of 1/60th sec: o simultaneously buffer and display odd half-frame i AND display previously buffered even half-frame i-1 o simultaneously buffer and display even half-frame i+1 AND display previously buffered odd half-frame i o simultaneously buffer and display odd half-frame i+2 AND display previously buffered even half-frame i+1 . . . Now, you see that even though objects are moved only at whole-frame intervals, you still get breakup because every other 1/60th sec two half frames are being displayed that DO NOT GO TOGETHER. The even half frame should either always be lower-numbered, or always higher-numbered, but in the above sequence they alternate. IF the fF buffered FOUR half-frames instead of two, then it could always display the correct pair. =->=-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. =- No. Absolutely wrong. Consider a horizontal line that is only one pixel high. In interlace, this will be part of the picture only every OTHER 1/60th of a second, double shuttered or not. It will flicker. Now consider an object that is only in every OTHER frame on a piece of film. It will flicker, double shuttered or not. Motion picture double-shuttering is used to eliminate JUMPINESS, *not* flicker. The double-shuttering gives the eye less time to fix the image, therefore adjacent images are not perceived as distinct. Once again: THIS IS NOT 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. =- *sigh*, no, I didn't mean interlaced frames, and changing a base register does NOT give you frames in any reasonable sense of the word. Frames occur at regular intervals, whether anything has changed or not. I challenge you to convince anyone that DMAing a screen's worth of data every 1/60th sec is in any way the same as changing an offset at random intervals. Sure, you have to change the base registers at regular intervals IFF you want to do ANIMATION. That is, unless you can update the whole displayed area of memory in less than the eye's perception time (conservatively, about 1/500th sec). THEN you don't even need page flipping for animation. For an 8000x8000 8-bitplane screen, that requires a 32 GHz processor--something I'm sure most of us will get to see in our lifetimes. (What's a 1000x speedup at Motorola these days, 2 years? :-)) And lest you try to say that such an update is a frame, too: no, it is not, because you don't HAVE to update the whole picture, only the parts that have changed. =-> 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. =- 'Snothing, mon. =->=-> 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? And *I* don't want to use that phrase at all! That's the whole point! (point of the argument, that is, not on the screen :-)) From the programmer's view, indeed the computer's, all that exists are polygons. Let's make it even simpler: all that exists are triangles. The computer says to the display device, 'here are three points and a color.' The display device then colors the region specified by the three points. Suppose the output device is a friendly little alien from pluto with a pane of glass and a box of crayons, who happens to speak RS-232. Where are the pixels?? ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|