bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/11/88)
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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
doug@eris (Doug Merritt) (04/11/88)
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
rchampe@hubcap.UUCP (Richard Champeaux) (04/12/88)
In article <8577@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > > 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. > > Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) > or ucbvax!unisoft!certes!doug Could you explain this a little more, I not sure I follow what you're saying. If you have a horizontal single pixle width line, it would be on the screen every other 1/60th of a second interval. (I might be wrong but I think you meant that each half-frame comes in every 1/60th of a second). What I'm trying to ask is: no matter how many times you display a half frame before the next one comes in, won't that horizontal line still be on the screen only every other 1/60th of a second interval? Excuse my comments if they seem stupid or have already been said, because I kind of dropped in the middle of this debate and missed the earlier messages. Rich Champeaux Clemson University
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/12/88)
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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
haitex@pnet01.cts.com (Wade Bickel) (04/12/88)
rchampe@hubcap.UUCP (Richard Champeaux) writes: >In article <8577@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: >> >> 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. > > Could you explain this a little more, I not sure I follow what you're >saying. If you have a horizontal single pixle width line, it would be on the >screen every other 1/60th of a second interval. (I might be wrong but I >think you meant that each half-frame comes in every 1/60th of a second). >What I'm trying to ask is: no matter how many times you display a half frame >before the next one comes in, won't that horizontal line still be on the screen >only every other 1/60th of a second interval? > I think Doug has the right idea, he was just not quite "explicit" enough. Let me give it a try. First lets define some terms; A video "frame" consists of two "fields" which occupy alternating scan-lines of the display. An interlaced picure is a "frame" consistings of two such fields. This terminoligy is standard in the video world so lets try to follow it to reduce future confusion. In this discussion lets refer to these as the odd and even fields, and assume that odd fields come first (I can't remember if this is true or not). Now on to flickerfixing. In the following example time is shown on the left in 60th sec.s. T = 0 : Capture odd feild #1. T = 1 : Display odd field #1. Capture even field #1. T = 1.5 : Display even field #1. T = 2 : Display odd field #1. Capture odd feild #2. T = 2.5 : Display even field #1. T = 3.0 : Display odd field #2. Capture even field #2 T = 3.5 : Display even field #2 Etc.... Since this is all synchronis, it can probably be done with something less than 2 full field buffers, but these must buffer RGB data. As I figure it you'd need about 2 megs of serially addressable memory, as opposed to RAM. Of course I have not really sat down and calculated this recently so this figure may be off. Also, an additionall 1/2 cycle of delay might be needed in the capturing of the fields, which would require slight adjustment to the description above. Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
walker@sas.UUCP (Doug Walker) (04/13/88)
In article <8557@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: >> 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".) Haven't you ever heard of vector graphics displays? It is quite possible to have a display system based on something other than pixels. The Evans and Sutherland PS-300 is a good example - the display is vector-based, meaning if a given area of the screen doesn't have anything drawn on it, the gun never passes over it. If you have fewer objects on the screen, it is easier to refresh each one more often; the more objects you have on the screen, the longer the minimum time between refresh cycles. Vector graphics have a lot of advantages over raster graphics, but unfortunately the technology isn't quite as advanced. I believe that as display resolution goes up, the likelihood of seeing vector displays again will also go up. Who wants to store a 8000x8000x24 bitmap anyway? Have you got 200 Meg to spare?
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/13/88)
In article <8651@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =-Ah. Ok, so Flicker Fixer *is* doing it wrong (presumably because of the =-extra expense of doing it right). Good, we've resolved one point. =- Yes, and this was the one and only point of my original article. Now, who's going to build one that does it right, and who's going to buy my fF when it come out? By the way, 'flickerFixer' is really the way MicroWay spells it, lest you all think that I can't type. Hence my abbreviation, 'fF'. =-> [...] 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. [...] =->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. =- =-I guess if you DMA *portions* of the RAM to the display at arbitrarily =-small intervals rather than at a fixed display rate, then the word "frame" =-becomes inappropriate...hmmm...interesting idea. *That* was what I was =-missing in my previous analysis. I like it! =- No, read that again, and recall that all of memory is ALSO a display device, just with a limited part visible at anytime, and the coordinates of that 'ViewPort' (now where did he get that word?) given by a pair of base registers. That means no DMA at all, ONLY writing to memory. Like it even better now? =->=-> Yes, yes, NOTHING is truly continuous on an arbitrarily small scale. =->=- [...] 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! =- =-Maybe it's just a question of terminology? I tend to think of grains in =-film as being more or less the same as pixels. It would seem that you =-consider that inappropriate. No problem. =-But what kind of mechanism do you have in mind? Would it be something =-similar to, say, outputting an (x,y) coordinate specified as two =-floats (along with perhaps a dot-size), and the "film-grain-equivalent" =-(or many of them for a macroscopic dot) near the center of that =-coordinate is what is addressed? If so, ok...again a nice idea. =-I can throw away the terminology "pixel == film grain" for that purpose. =- Yes, it's a question of terminology, but it's not arbitrary. There are good reasons why the two terms mean different things: While it is true that both define a lower bound on resolution (though pixels are more uniform), the important difference is that when you draw something on a display that has pixels, you have to color EACH ONE individually. Someone mentioned vector displays in another article. I didn't want to get that specific, but it illustrates the point. When you draw a line on a vector display, all you specify are the endpoints. Does the display have grains? Yes. Does it have pixels? NO. I explained the mechanism I have in mind. Once again: everything is specified as a triangular area, a set of three coordinate pairs. If you want a line, make two of the points the same. If you want a point, make all three the same. The grain size may be determined by the arithmetic precision of the coordinates, or by the physical medium. But there are no 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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/13/88)
In article <8649@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes: =-time (in 1/120 sec): 0 1 2 3 4 5 6 7 8 9 10 11 12 =-time (in 1/60 sec): 0 1 2 3 4 5 6 =-time (in 1/30 sec): 0 1 2 3 =-half-frame displayed: ... 1 2 1 2 3 4 3 4 etc =-full-frame displayed: ... 1 1 1 1 2 2 2 2 etc =- =-The "..." represents time spent gathering the first two half-frames =-in the first 30th of a second, so that they can be displayed at a higher =-rate than they were generated, in the next 30th of a second. =- =-This shows a full-frame being generated and displayed each 30th of =-a second. But each half-frame is displayed twice within that interval =-(e.g. half-frame number two appears twice in the first 30th sec). =-It's true that you don't get a new set of two-half frames until a =-full 30th of a second goes by, and that has second-order effects, =-but the first order effect is simply a question of stroboscopic flicker, =-which perceptually disappears around 40 to 45 hertz. Since you're =-strobing half-frame two at 60 hertz, there's no stroboscopic flicker. =- Aha, so you want to INTERLEAVE the two fields (heretofore 'half- frames'). I suspected that this was what you meant, but I was being deliberately obtuse so I could act superior. :-) Yes, this will work, but you STILL have to buffer four fields to prevent breakup. Therefore, all this might buy you is... =-The second-order effect is smoothness of motion. Consider times you've =-seen a film/vcr played in slow motion. If it was filmed at the regular =-rate, motion looks jerky in slow motion even though there's no stroboscopic =-flicker. It's not the whole picture that looks jerky/flickery, as it =-does at slow frame display rates, it's just the motion itself. =- Now you're on track. Your method would be smoother. Except that as the frame rate increases, the effect of double-shuttering decreases. A double- shuttered, 24 frame/sec film gives the eye 1/48th sec to fix the image. A properly working flickerFixer gives it slightly longer--1/30th sec. Let's say, for the sake of argument, that the image-fixing time of the eye is somewhere around the perceptual stroboscopic threshhold (say that three times fast), which you give as ~40Hz, i.e. 1/40th sec. (1/40)/(1/30) = 1.33, so the fF video is only 33% more jumpy than 'real motion,' assuming a linear relationship, whereas un-double-shuttered film is 67% more jumpy. Your method shows each field for 1/120th second, which is 200% LESS jumpy than reality (no existentialist humor, please). This seems a little excessive, if the cost of a 120Hz display is going to be about twice that of a 60Hz display, which is a reasonable assumption. ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
hedley@cbmvax.UUCP (Hedley Davis) (04/13/88)
In article <1367@hubcap.UUCP> rchampe@hubcap.UUCP (Richard Champeaux) writes: >In article <8577@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: ....Lots of deleted text about Fixing Flicker and the FlickerFixer....... I just thought I'd throw some idle thoughts into the fray. FlickerFixer design flaw: The FlickerFixer design is not flawed given the boundary values of the problem. As was previously stated, ( by someone else whose .sig I've lost ), the information which comes from the amiga for adjacent lines is separated in time by 1/60 th of a second. In this time, animated objects have moved and therefore you have the 'split image' artifact that is being complained about. True this artifact is not desirable, but the only solution is to change the in which the data is emitted from the amiga, IE software change. The flickerfixer is totally software compatible, indeed from the perspective of the board, it has no ability to change the system software, and hence, fetch ordering of bitplane or sprite data. Given this constraint, its about the highest degree of functionality you can get. A minor point: 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. The reason for this is that you only need to hold onto data for 1/60th of a second ( displaying it twice ) before it becomes obsolete. The minimum-ram implementation of this type of device requires a large circular buffer where only 200+ lines are stored. About film and 24 Hz and double shuttering. 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 ). 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. Further, this display type is indeed much more expensive for a marginal improvement in perceived display quality. Hedley
doug@eris (Doug Merritt) (04/14/88)
In article <11226@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: >specified as a triangular area, a set of three coordinate pairs. If you want a >line, make two of the points the same. If you want a point, make all three >the same. The grain size may be determined by the arithmetic precision of the >coordinates, or by the physical medium. But there are no pixels. Ok. This line of discussion (plus the vector posting) clarifies what you meant; I was kind of stuck in one line of thinking before. > [...] and recall that all of memory is ALSO a display >device, just with a limited part visible at anytime, and the coordinates of >that 'ViewPort' (now where did he get that word?) given by a pair of base >registers. That means no DMA at all, ONLY writing to memory. Like it even >better now? This is the final point that I still don't see. If all of memory is the display device, does that mean that you're not using normal RAM? I simply cannot visualize how this is supposed to work. Even if the display device *is* your main memory, what does that *mean* ? Does it contain RAM that it moves to Pixels or Smudges? ("Smudges" == nonpixels, of course. Or would "Trixels" -- Triangular Picture Elements be better? :-) You said you "didn't want to get this specific", but without more specifics I have difficulty seeing what you have in mind. So far it *sounds* like a mutually exclusive set of specifications. Can you clarify? Ideally what I'm after here is an architectural description; the display could be Alien Crayons, but how is it functionally linked to memory?? Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
doug@eris (Doug Merritt) (04/14/88)
In article <11227@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: >In article <8649@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes: >=-time (in 1/120 sec): 0 1 2 3 4 5 6 7 8 9 10 11 12 >=-time (in 1/60 sec): 0 1 2 3 4 5 6 >=-time (in 1/30 sec): 0 1 2 3 >=-half-frame displayed: ... 1 2 1 2 3 4 3 4 etc >=-full-frame displayed: ... 1 1 1 1 2 2 2 2 etc >=-This shows a full-frame being generated and displayed each 30th of >=-a second. But each half-frame is displayed twice within that interval >=-(e.g. half-frame number two appears twice in the first 30th sec). > >STILL have to buffer four fields to prevent breakup. Therefore, all this might Huh? You lost me...in the above diagram, first fields #1 and #2 are buffered, and then fields #3 and #4...that's only *two* at a time. Where did "four" come from? Hmmm...do you mean in terms of memory requirements? It's true that you have to capture 3 & 4 while displaying 1 & 2, that's four frames, for sure. But it sounded like you were talking about something else. BTW I eventually come to realize that this 120 hz scheme is overkill, based on your comments, but first a few other issues: >=-The second-order effect is smoothness of motion. [ ... ] > Now you're on track. Your method would be smoother. [ ... ] >is only 33% more jumpy than 'real motion,' assuming a linear relationship, >whereas un-double-shuttered film is 67% more jumpy. Your method shows each >field for 1/120th second, which is 200% LESS jumpy than reality (no That would be nice, wouldn't it? Unfortunately, it requires intermediate *generated* frames as well as *displayed* frames, to show the intermediate positions of moving objects, to smooth *motion*. The Amiga can't really generate them, because it can only send out fields at 60hz (and frames at 30hz of course). On the other hand, it's feasible (though difficult) to *interpolate* those frames. See work done by the "Advanced Television" research group at the MIT Media Lab; the perceptual smoothing of jerky motion is quite noticeable. So again, all this fancy 120hz scheme (without motion interpoloation) does is eliminate *stroboscopic* flicker, not *motion* jerkiness. It'll look *exactly* like the Amiga's current interlaced display, but with no flicker whatsoever. >This seems a little excessive, if the cost of >a 120Hz display is going to be about twice that of a 60Hz display, which is a >reasonable assumption. *At least* twice as expensive, yes. Plus quite a bit of extra cost if one adds real-time motion interpolation hardware! So yeah, it's excessive in terms of cost. But it would look real nice! Of course, your analysis points out that all this is overkill, without motion interpolation, because if the flickerFixer did things "right", it too would look just like the Amiga's interlaced display, only without flicker. And it would only need a 60hz frame rate to do so. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/14/88)
In article <2954@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: =- Well, I wouldn't go as far as saying FF is flawed, it does what it was =-designed to do. Remove flicker. =- Oh? Gee, you must still be driving a 1975 Pinto. It too does what it was designed to do, only it has this tendency to come apart under certain conditions. And here all these years I thought it was a flawed design. =- However you are correct in saying that an object can come apart. I just =-saw this last night by accident. But, and a big one at that, it was visible in =-the silly and useless boxes demo. I guess this demo blits so fast, it exceeds =-the 30HZ display rate of video. It was barely perceivable. The only reason I =-noticed it, was it just didn't "look" right. You would never know if you had =-never seen the demo without FF, and 2 amiga's side by side. =- =- On the other hand, I would defy you to create a "useful" animation =-that would make this "defect" perceptable, much less objectionable. =- =- Are we worried about the Amiga going trans-warp? I'm not trying to =-be nasty, but if you can, I'd like to see it! =- If you read my latest article, you will see it plainly stated why objects DO come apart even thought the motion is synched to the 30Hz display rate. If you really did see the fF in action, then you saw the mouse pointer come apart, and you will see it in every animation that moves anything faster than 1 pixel/(1/30th sec). =- I'm not 100% sure you would need to buffer even 2 frames. If I =-were a clever engineer, I would use a dual port video ram to clock out one =-half-frame at twice the speed, along with the other, while a half-frame was =-being clocked in slower, behind the first half-frame going out. How's that =-for total confusion! =- See if you still say this when you've thoroughly understood the problem. =- I suggest you guys chew on this a bit. =- Ick! Not after you've touched it! ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
doug@eris (Doug Merritt) (04/14/88)
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 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. 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. > 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. You *do* need 400 lines (plus a couple) for "correct" 60hz flicker fixing. You need to merge the two fields and display them once (you could get away with 200 lines just for this), and then display them both *again* at the same time you're using the extra couple lines to begin grabbing the start of the next field. The reason is that, by the time you need to display the whole frame the *second* time, the original two fields are gone and you're moving on to grabbing the *next* two fields. This means you can't simply mix in the second of the fields with the first as you get it. > 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. It's double shuttered...each frame is displayed twice, not three times. See "Motion Pictures, Technology of". The section on Television mentions the same fact. And of *course* the purpose is to eliminate flicker; that is the only reason they bother to double-shutter. Edison's projector ran at 46 frames per second. Multi-shuttering was introduced in 1895 purely to allow a savings of film by dropping the recording rate to 15 to 18 frames per second. They *did* do triple-shuttering back then, maybe that's what you're thinking of. 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. >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.) 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
dca@kesmai.COM (David C. Albrecht) (04/15/88)
In article <11234@ut-sally.UUCP>, bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes: > In article <2954@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > =- Well, I wouldn't go as far as saying FF is flawed, it does what it was > =-designed to do. Remove flicker. > =- > Oh? Gee, you must still be driving a 1975 Pinto. It too does what it > was designed to do, only it has this tendency to come apart under certain > conditions. And here all these years I thought it was a flawed design. > > If you read my latest article, you will see it plainly stated why > objects DO come apart even thought the motion is synched to the 30Hz display > rate. If you really did see the fF in action, then you saw the mouse pointer > come apart, and you will see it in every animation that moves anything faster > than 1 pixel/(1/30th sec). > If you're so smart why ain't you rich. The FACT is, fF is the only product so far which addresses the flicker problem on the Amiga. LP phosphor monitors have their own set of problems which are more objectionable than and cost as much or more than the fF solution. If you find the design so flawed then don't buy it. Better yet, build a non-flawed solution and we will all thank you rather than argue with you. Flawed or not, it fF does fix the flicker and at a fairly reasonable cost. Personally, unless something better comes along, at some point I hope to get together the scratch for fF and a multi-sync and have one on my desk. I find the picture coming apart much less objectionable than I find flicker. At least the fF people have made an attempt at a solution (which some people at least find useful). David Albrecht
bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer) (04/15/88)
In article <3626@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: =-The FlickerFixer design is not flawed given the boundary values of the =-problem. As was previously stated, ( by someone else whose .sig I've =-lost ), the information which comes from the amiga for adjacent lines is =-separated in time by 1/60 th of a second. In this time, animated objects =-have moved and therefore you have the 'split image' artifact that is =-being complained about. True this artifact is not desirable, but the =-only solution is to change the in which the data is emitted from the =-amiga, IE software change. The flickerfixer is totally software =-compatible, indeed from the perspective of the board, it has no ability =-to change the system software, and hence, fetch ordering of bitplane or =-sprite data. Given this constraint, its about the highest degree of =-functionality you can get. =- What sort of logic is this? Just because things moved in 1/60th second intervals will break up WITHOUT the flickerFixer doesn't excuse the fact that objects moved every *1/30th* second break up WITH fF. For the nth time: the problem is that fF displays two 200-line fields that DO NOT GO TOGETHER. This is NEVER the case in the normal interlaced display, therefore software written to synch at 1/30th second will look right, whereas with fF it WILL NOT, if the rate of movement exceeds 1 pixel every 1/30th second. Am I not correct in stating that the mouse pointer is moved by the system every 1/30th second? If this is true, then it should NEVER break up if two matched fields are always displayed together. But it does! See: I'm waving it at you right now! I don't know how to make it any clearer. :-) ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer) (04/15/88)
In article <8691@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =-In article <11226@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: =-> [...] and recall that all of memory is ALSO a display =->device, just with a limited part visible at anytime, and the coordinates of =->that 'ViewPort' (now where did he get that word?) given by a pair of base =->registers. That means no DMA at all, ONLY writing to memory. Like it even =->better now? =- =-This is the final point that I still don't see. If all of memory is the =-display device, does that mean that you're not using normal RAM? I simply =-cannot visualize how this is supposed to work. Even if the display =-device *is* your main memory, what does that *mean* ? Does it contain =-RAM that it moves to Pixels or Smudges? ("Smudges" == nonpixels, of course. =-Or would "Trixels" -- Triangular Picture Elements be better? :-) =- =-You said you "didn't want to get this specific", but without more =-specifics I have difficulty seeing what you have in mind. So far it =-*sounds* like a mutually exclusive set of specifications. Can you clarify? =-Ideally what I'm after here is an architectural description; the display =-could be Alien Crayons, but how is it functionally linked to memory?? =- Yes, I can see where confusion might arise. I've been treating these as two separate lines of discussion. They are indeed mutually exclusive specifications: The 'non-frame' system has nothing to do with the 'non-pixel' system. Now, is there still a problem when, as you said, you think of the display device as BEING your one and only memory? Or with the OTHER system, in which there is NO memory map of the display (which would imply pixels) in the usual sense? ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer) (04/15/88)
In article <8693@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes: =->STILL have to buffer four fields to prevent breakup. Therefore, all this might =- =-Huh? You lost me...in the above diagram, first fields #1 and #2 are buffered, =-and then fields #3 and #4...that's only *two* at a time. Where did "four" =-come from? Hmmm...do you mean in terms of memory requirements? It's =-true that you have to capture 3 & 4 while displaying 1 & 2, that's four =-frames, for sure. But it sounded like you were talking about something else. =- Yes, exactly, I mean in terms of memory requirements. I wouldn't say that fields being displayed are not being buffered, but if you like... In this case fF buffers NOTHING. That sounds really bad. After having spent the $448, I like my terminology better. :-) =-BTW I eventually come to realize that this 120 hz scheme is overkill, =-based on your comments, but first a few other issues: =- =->=-The second-order effect is smoothness of motion. [ ... ] =-> Now you're on track. Your method would be smoother. [ ... ] =->is only 33% more jumpy than 'real motion,' assuming a linear relationship, =->whereas un-double-shuttered film is 67% more jumpy. Your method shows each =->field for 1/120th second, which is 200% LESS jumpy than reality (no =- =-That would be nice, wouldn't it? Unfortunately, it requires intermediate =-*generated* frames as well as *displayed* frames, to show the intermediate =-positions of moving objects, to smooth *motion*. The Amiga can't really =-generate them, because it can only send out fields at 60hz (and frames =-at 30hz of course). On the other hand, it's feasible (though difficult) =-to *interpolate* those frames. See work done by the "Advanced Television" =-research group at the MIT Media Lab; the perceptual smoothing of jerky =-motion is quite noticeable. =- =-So again, all this fancy 120hz scheme (without motion interpoloation) =-does is eliminate *stroboscopic* flicker, not *motion* jerkiness. It'll =-look *exactly* like the Amiga's current interlaced display, but with no =-flicker whatsoever. =- It becomes clear to me now that flicker is really being used in two related but different ways. Therefore I propose the following, more precise definitions: Flicker: A perceived INTERMITTENCE in an ENTIRE image, as in successive frames interleaved with intervals of 'darkness' (= absence of image). Jitter: A perceived MOTION of an image COMPONENT due to PARTIAL images being interleaved, as in interlaced displays. Jerkiness: A perceived DISCONTINUITY of motion, due to a slow frame rate. Now I claim the following: -Double-shuttering addresses FLICKER, by equalizing the on and off intervals for a frame. -flickerFixer should really be called jitterFixer. -Nothing but a higher frame rate or interpolation helps jerkiness. (i.e., Doug is right, above.) ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
harald@leo.UUCP ( Harald Milne) (04/15/88)
> I've had a MicroWay flickerFixer installed in my 2000 for about a week >any object on the screen moving faster than 1 pixel every 1/30th second 'comes >apart' into two images consisting of the odd and even scan lines of the object, Do you see this with your own eyes or on a frame by frame VCR? -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
harald@leo.UUCP ( Harald Milne) (04/15/88)
> It becomes clear to me now that flicker is really being used in two > related but different ways. Therefore I propose the following, more precise > definitions: > > Flicker: A perceived INTERMITTENCE in an ENTIRE image, as in successive > frames interleaved with intervals of 'darkness' (= absence of image). For us normal Amiga types, this is called "Non interlaced" Where alternate "half frames" are absent. That gives us the lines without information in non interlaced modes. > Jitter: A perceived MOTION of an image COMPONENT due to PARTIAL > images being interleaved, as in interlaced displays. For us normal Amiga types, this is called "Interlaced". It is also called flicker. You can call it what you like. > Now I claim the following: > -flickerFixer should really be called jitterFixer. Call it whatever you like, but for heaven's sake, go away. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
doug@eris (Doug Merritt) (04/16/88)
=-In article <11254@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: > Now, is there still a problem when, as you said, >you think of the display device as BEING your one and only memory? Yes, that's the one that I can't see the archetectural subsystem for. How could just this case (neglecting pixels vs. nonpixels) work the way you specified? The reason I can't see it is that it seems like all that happened is that the functionality that used to be in the cpu box (like writing to RAM, then DMA'ing it to a memory mapped display) simply got moved out into the display itself. Yet I get the impression that that's not what you had in mind. But I don't see any significantly different way of doing it inside the display than without. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
doug@eris (Doug Merritt) (04/16/88)
In article <11255@ut-sally.UUCP> bryan@gamera.cs.utexas.edu writes: > -Flicker: A perceived INTERMITTENCE in an ENTIRE image, as in successive > frames interleaved with intervals of 'darkness' (= absence of image). > -Jerkiness: A perceived DISCONTINUITY of motion, due to a slow frame rate. > -Double-shuttering addresses FLICKER, by equalizing the on and off > intervals for a frame. > -Nothing but a higher frame rate or interpolation helps jerkiness. I agree with all of this. > Jitter: A perceived MOTION of an image COMPONENT due to PARTIAL > images being interleaved, as in interlaced displays. I think "jitter" as defined here is an unnecessary term, since it only results from buggy timing (software: synchronized to a 60hz rate rather than 30; hardware: what fF does). > -flickerFixer should really be called jitterFixer. Maybe, since it's got the bug necessary for your definition of jitter above. This means that we use the term "jitter" just to describe buggy hardware and/or software? Self-consistent, but I'm not sure it'll catch on...there are a lot of people who use "jitter" and "flicker" interchangeably. Perhaps rather than using a specialized meaning for the word, we instead need to encourage fF (and anyone else with that bug) to do things right. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
doug@eris (Doug Merritt) (04/16/88)
In article <160@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: >In article <11234@ut-sally.UUCP>, bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes: >> rate. If you really did see the fF in action, then you saw the mouse pointer >> come apart, and you will see it in every animation that moves anything faster >> >If you're so smart why ain't you rich. The FACT is, fF is the only product >so far which addresses the flicker problem on the Amiga. [ ... ] >apart much less objectionable than I find flicker. At least the fF people >have made an attempt at a solution (which some people at least find useful). Although apparently well-intentioned, your critique of Bryan is not to the point. Using your logic, no one on the net should ever claim that any hardware or software product is flawed or has bugs, because "at least they made an attempt at a solution". I think you'll find that most people disagree...knowing about problems in products is very important, and prior to the start of this discussion, I was not aware that fF was flawed. Now I feel that we all understand exactly what it does right, what it does wrong, and how it could be improved (well, those of us who've been reading and thinking carefully about it, anyway :-). Many people will want to buy it anyway, since it is a partial solution. Others, like me, will want to wait for a better product, even if it is more expensive, and may take a while to become available. BTW note that de-interlaced televisions are (I think) now available, and will shortly become common. See quotes in Stewart Brand's "The Media Lab". Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/16/88)
In article <160@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: =-In article <11234@ut-sally.UUCP>, bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes: =-> In article <2954@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: =-> =- Well, I wouldn't go as far as saying FF is flawed, it does what it was =-> =-designed to do. Remove flicker. =-> =- =-> Oh? Gee, you must still be driving a 1975 Pinto. It too does what it =-> was designed to do, only it has this tendency to come apart under certain =-> conditions. And here all these years I thought it was a flawed design. =-> =-> If you read my latest article, you will see it plainly stated why =-> objects DO come apart even thought the motion is synched to the 30Hz display =-> rate. If you really did see the fF in action, then you saw the mouse pointer =-> come apart, and you will see it in every animation that moves anything faster =-> than 1 pixel/(1/30th sec). =-> =-If you're so smart why ain't you rich. The FACT is, fF is the only product =-so far which addresses the flicker problem on the Amiga. LP phosphor =-monitors have their own set of problems which are more objectionable than =-and cost as much or more than the fF solution. If you find the design so =-flawed then don't buy it. Better yet, build a non-flawed solution and we =-will all thank you rather than argue with you. Flawed or not, it fF does =-fix the flicker and at a fairly reasonable cost. Personally, unless something =-better comes along, at some point I hope to get together the scratch for =-fF and a multi-sync and have one on my desk. I find the picture coming =-apart much less objectionable than I find flicker. At least the fF people =-have made an attempt at a solution (which some people at least find useful). =- This sort of irresponsible flame contributes nothing to the discussion, and makes its originator look like someone who is either incapable of grasping the issues, or like someone who came in in the middle and didn't bother to go back a couple of articles to see what it was all about before burdening the rest of us with a paragraph of nonsense. That said, let me respond: Just because something is a partial solution to a problem, even the ONLY existing partial solution, is no reason not to criticize it. Following your logic, technological development would have come to a halt about ten minutes after it began. Moreover, the discussion is about the REASONS why the design is flawed, not whether the people at MicroWay should be killed for producing it, as you seem to imply. I fail to see how you could have read anything like that into this series of articles, except that your comments indicate that being judgemental is endemic to your reasoning, so you are incapable of understanding how anyone else might not be. I sincerely hope that that's not the case: there's enough of that about as it is. IF you had been following this from the beginning, you would know that I DID buy the flickerFixer. My only purpose in starting this thread was to make people aware of the problem, and to discuss ways in which it could be solved. Never once did I say, "gee, I'm sorry I wasted my money on this-- don't buy it, it sucks." In fact, I'm quite happy with the fF, since I think I got my money's worth. A fF without the breakup problem would be nice, but it would also cost a good deal more, since the memory would have to be doubled, which would be a tight squeeze in the space above the video slot. Oh yeah: I *am* rich. 8-} ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/16/88)
In article <8776@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =- =-> Jitter: A perceived MOTION of an image COMPONENT due to PARTIAL =-> images being interleaved, as in interlaced displays. =- =-I think "jitter" as defined here is an unnecessary term, since it only =-results from buggy timing (software: synchronized to a 60hz rate rather =-than 30; hardware: what fF does). =- Well, no. What I meant by motion was 'motion that's not really there.' A normal, unflickerFixered interlaced display has JITTER at the horizontal edges of an image component. The more horizontal edges an image has, the more jitter it has. fF removes this by removing interlacing. Hence 'jitterFixer.' I should have been clearer about the term 'motion.' ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
haitex@pnet01.cts.com (Wade Bickel) (04/16/88)
I fail to see the productivity of this topic and am growing tired of
the condecending tone sometimes being used. Simply put, with enough RAM and
a 120hz monitor true flicker fixing could be accoplished. But, it would only
improve interlace displays, and should effectively be disabled on
non-interlaced displays. Since the costs are high and the benfits are
limited, only professionals or very serious hobbiests might purchase this
stuff (if it existed), so as developers we should ignore it because this is
such a *small* part of the market.
I for one would love to see a Video-Double buffering unit at just
about any reasonable price (say under $1000). In working on stere-3D, and
the frame rate issue is much more important here. Any of you hardware types
have any ideas?
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMuzun@wolf.UUCP (Roger Uzun) (04/17/88)
After watching the flames fly for a week or so here I must interject, i have had a flickerfixer hooked to my A2000 for about 2 months now on botha Zenith ZCM-1490 Flat Tension Monitor and a Sony CDP-1302 Multiscan Monitor. I have also been playing aroound with animation routines in that time and I can categorically state that object -=>DO<=- come apart when using it. It looks like every object has a slightly serrated edge on both sides and to me is not at all objectionable but if I had my choice I would rather it not be there. It does fix the flicker problem in interlace mode and thats what I bought it for, since I have been doing a radar display where I work and this must be in 640X400 mode I find it an excellent display solution to my problem, but I recomend to anyone who wants one to look at the serrated edge effect that it causes on all animation objects and decide for themselves if they like it. I would much rather have slight edges on my animation objects then 1/4" gaps between scan lines!!!(I find scan line gap very objectionable and rough edges on sprites and bobs much less so -=> BUT THIS IS MY PERSONAL OPINION ONLY <=- NOTE : Because of the scan line gap fill function of flicker fixer bobs and sprites in non interlace mode also have serrated vertical edges!! -Roger
farren@gethen.UUCP (Michael J. Farren) (04/17/88)
In article <453@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >Haven't you ever heard of vector graphics displays? > >Vector graphics have a lot of advantages over raster graphics, but >unfortunately the technology isn't quite as advanced. I believe that as >display resolution goes up, the likelihood of seeing vector displays again >will also go up. Possibly, but probably not. Vector displays have two big advantages. First, they're FAST - especially if you don't have a high density display. Second, they are unexcelled at displaying lines, as the lines aren't made up of pixels (jaggies), but are single units, drawn in one stroke. Unfortunately, you pay some rather stiff prices for these two advantages. The electronics involved in making a good, stable vector display monitor are non-trivial. There are many considerations that just don't apply to a raster-scan monitor. You have to compensate for the varying speed of drawing when you are drawing at an angle. You have to have fairly sophisticated circuitry to avoid distortion of the image. You have to have circuitry to ensure that the display doesn't develop unevenly distributed static charges which will cause additional distortion. On top of that, there is one SCREAMING disadvantage - you don't get color. Well, more precisely, you don't get good, clean color. While it is possible to use a standard 3-gun (or 1-gun trinitron type) CRT as a vector display, the convergence problems are huge, and expensive. Vector displays aren't likely to take over any time soon. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
farren@gethen.UUCP (Michael J. Farren) (04/17/88)
In article <2972@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: >> Flicker: A perceived INTERMITTENCE in an ENTIRE image, as in successive >> frames interleaved with intervals of 'darkness' (= absence of image). > > For us normal Amiga types, this is called "Non interlaced" >Where alternate "half frames" are absent. That gives us the lines without >information in non interlaced modes. This is not what happens at all. Non-interlaced mode does NOT have "lines without information", and alternate half-frames are NOT absent. The difference is simply that in non-interlace, the lines are displayed in the same position on the screen each 60th of a second. What you get are 60 screens per second, each 200 lines tall. In interlace mode, every other half-frame is displayed on the screen such that it falls between the lines of the preceding half-frame. Thus, you get a total of only 30 screens per second, each 400 lines tall. There are no "lines without information" in either mode. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
aleks@well.UUCP (Brian J. Witt) (04/18/88)
In article <8557@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: >In article <11182@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: > >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). Presumably you could >do this by sending the display a set of simultaneous differential >equations which it would then display as continuous curves/surfaces. >You have both continous (infinitely precise) positioning (spatial phase), Sure, I'd like a display that accepted differential equations as input. I now it's not the thread, but the thread is enjoyable! It's a lot better than programming language wars =(:-|). BTW: if you animate 30 frames/second, what keeps you from changing the image on the other-every frame the fF does grab (I know little of how it works, but could understand). -- I bought it for the multi-tasking, and the salesperson sez it does graphics, too! brian :w
doug@eris (Doug Merritt) (04/18/88)
In article <2972@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > [Bryan wrote: ] >> Jitter: A perceived MOTION of an image COMPONENT due to PARTIAL >> images being interleaved, as in interlaced displays. ^^^^^^^^^^ >For us normal Amiga types, this is called "Interlaced". It is also That's what he said, Harald. >> Now I claim the following: >> -flickerFixer should really be called jitterFixer. >Call it whatever you like, but for heaven's sake, go away. Why not use your "j" or "k" (or "u") key, Harald. He's not flaming, he's talking about a technical subject...who appointed *you* the net censor? Why don't *you* go away? Or at least quit bothering us? Very few people have been posting comments on this discussion that Bryan and I have been having, so perhaps there's not a *lot* of interest in the topic. That's fine...if you're not interested, don't read it! FLAME ON: And...it's interesting that this miniflame above ("go away") came from someone who seems to have a great deal of difficulty understanding the subject at hand, based on his poorly thought-out rebuttals that Bryan and I dealt with explicitly already. Perhaps he wishes we'd stop talking about a subject that makes his brain hurt from the strain of thinking about it. For instance, just a couple of postings ago Harald *implies* (my interpretation of his posting) that the problem of images breaking up is an optical illusion that wouldn't occur if viewed in slow motion on video tape. This demonstrates very thoroughly how little Harald understands about either the problem, which we've analyzed in painstaking detail, or probably human perception, too. I presume he *implied* this point, by asking a question, rather than saying it directly, in order to put the burden of proof on Bryan, knowing he (Harald) was on thin ice. No big deal, he's not required to be intelligent or well informed or to thoroughly read our postings that would help remedy the latter lacks. Until he tells Bryan to shut up. At which point I take strong exception. FLAME OFF. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
hedley@cbmvax.UUCP (Hedley Davis) (04/18/88)
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
hedley@cbmvax.UUCP (Hedley Davis) (04/18/88)
In article <11253@ut-sally.UUCP> bryan@gamera.cs.utexas.edu writes: >In article <3626@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: > >=-The FlickerFixer design is not flawed given the boundary values of the >=-problem. As was previously stated, ( by someone else whose .sig I've >=-lost ), the information which comes from the amiga for adjacent lines is >=-separated in time by 1/60 th of a second. In this time, animated objects >=-have moved and therefore you have the 'split image' artifact that is >=-being complained about. True this artifact is not desirable, but the >=-only solution is to change the in which the data is emitted from the >=-amiga, IE software change. The flickerfixer is totally software >=-compatible, indeed from the perspective of the board, it has no ability >=-to change the system software, and hence, fetch ordering of bitplane or >=-sprite data. Given this constraint, its about the highest degree of >=-functionality you can get. >=- > What sort of logic is this? Just because things moved in 1/60th >second intervals will break up WITHOUT the flickerFixer doesn't excuse the >fact that objects moved every *1/30th* second break up WITH fF. For the >nth time: the problem is that fF displays two 200-line fields that DO NOT >GO TOGETHER. This is NEVER the case in the normal interlaced display, >therefore software written to synch at 1/30th second will look right, >whereas with fF it WILL NOT, if the rate of movement exceeds 1 pixel every >1/30th second. Am I not correct in stating that the mouse pointer is moved >by the system every 1/30th second? If this is true, then it should NEVER >break up if two matched fields are always displayed together. But it does! >See: I'm waving it at you right now! I don't know how to make it any >clearer. :-) > Did'ja ever see that famous Saturday Night Live imitation of the old news segment 'Point/Counterpoint' ? The one where the Dan Ackroyd (sp?) responds to the opening comments made by Jane Curtain with 'Jane, you ignorant Slut !' ? Bryan, you ignorant Scum ! You are wholly incorrect. Inutition updates the pointer location at 60 Hz regardless of whether the display is interlaced or not. So, no matter what kind of deinterlacer you have , two feild store, or one feild store, the pointer will break up. Now, it is quite academic that this could be changed, but don't claim my spam content is high when you haven't even got your facts down. And don't go spouting off about the system being incorrect either. The system updates the pointer at 60 hz on an interlaced display because this splitting artifact does not show up without a flicker fixer. Therefore, the display looks better because motion is better smoothed. You always could request a new preferences setting to slow the system pointer updates. :-) Hedley ( I am presuming that you mistated your opening comments about things being moved 60 time a second breaking up without a flicker fixer. If this is indeed you opinion, then you oughta try some experimention. Look at the sprite, it looks ok without a flicker fixer, right ? ).
avery@puff.cs.wisc.edu (Aaron Avery) (04/18/88)
In article <2969@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: >> I've had a MicroWay flickerFixer installed in my 2000 for about a week >>any object on the screen moving faster than 1 pixel every 1/30th second 'comes >>apart' into two images consisting of the odd and even scan lines of the object, > > Do you see this with your own eyes or on a frame by frame VCR? When was the last time YOU tried to display a 524 line display being refreshed at 60Hz noninterlaced on a frame by frame VCR???? (meaning: it's not possible, as what comes out of the flickerFixer is not NTSC anymore) -- Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)
haitex@pnet01.cts.com (Wade Bickel) (04/18/88)
Not sure if this will make it to comp.sys.amiga.tech, but here
goes anyway...:^). (My last two postings bounced!)
Anyway, I just wanted to point out a peice of flawed reasoning I had
seen.
Someone had concluded that in order to remove "jitter" (as currently
being discussed elsewhere in this thread) from 120hz double buffered
flicker fixing it would be necessary to interpolate intermediate
fields using specialized hardware. Note however, that since the frame
rate is so high, the "jitter" will be imperceptable and at any given
time two full fields will appear to be displayed at once with no
flicker. Even though the images will in fact be moving in a stuttering
manner to the viewer it will appear as smooth motion.
The point is that simply double buffering the RGB out should do the
trick. Seems to me that if it were done properly it would be an
independant product, working on any system which can provide RGB
(digital) output.
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMbryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (04/19/88)
In article <8862@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =-In article <2972@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: =- =-> [a pageful of belligerent garbage] =- =-FLAME ON: =- =- [Doug reduces Harald to a pile of smoking ashes] =- =-FLAME OFF. Yeah! What Doug said! I was going to respond to this flagrant display of intellectual and social incompetence, but Doug has already done it so eloquently that there is nothing I could add. ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _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 |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
doug@eris (Doug Merritt) (04/19/88)
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
doug@eris (Doug Merritt) (04/19/88)
Before getting into specifics, thanks, Hedley, for taking the trouble to research your response. With an exception or two I address below, but don't worry, there's no flames. [ Hedley, me, then Hedley again: ] >>>The FlickerFixer design is not flawed given the boundary values of the ::Incorrect. The software may *already* be synched to a 30hz display > 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. I didn't realize that was the case; I must have misunderstood your wording. Sorry! And your example of Intuition moving the pointer at a 60hz rate is well taken. But to return to the *original* point: simply that flickerFixer would work better if it *only* merged the odd and even scan fields of a single frame. This would not break *existing* software that did interlaced animation at a 30hz update rate. By which I mean software which is taking advantage of 400 lines of detail, which can be animated at a maximum 30hz rate. The example of Intuitions pointer is different; if you're animating at a 60hz rate then you only have half the detail. Also my suggestion for an improved design would at least allow the possibility for, e.g. Intuition to precompensate in a future release (using motion blur, presumably. Or a simple 30hz update rate). I'll hit this from a different angle again below, possibly more clearly. >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 ? Interesting. Is that good or bad? >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. No. "happen to swap" isn't right...I'm claiming that anything that animates a full 400 lines of detail at 30hz (which some people certainly do!) is already swapping on the correct field, and that *this* is what fF breaks. >= [ Further derivations of theroms based on afformentioned >= inconsitant logic deleted. ] Come on now. Let me try again from another point of view. Whatever is shown on an interlaced display is either 1) being updated at a 60hz rate, in which case fF is doing the best it possibly can, and any flicker fixing design would merge the previously separate images, or else 2) the interlaced display is being updated at 30hz because all 400 lines are significant, and the software is ignoring the fact that it takes two fields to make up a full frame, in which case fF is flawed because it merges *all* adjacent fields, not just the correct even and odd fields of each frame. Both techniques can be found in existing software. fF is perfect for case #1, it is flawed for case #2. >=By the way, the reason for the approximate range of values (40-45hz) [...] >=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. > >Flicker perception depends not only on contrast, but brightness as well. True. Since we're on the subject, thanks for the clarification. >The reason films in theaters do not flicker is that they are shown in a >darkened enviroment. Oops, nope, the dark *increases* contrast...but it still happens to be in the right range. >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.' True. Note above I said "above 45hz you're generally considered safe". I put the word "generally" in there to avoid going into a bunch of extraneous detail (this *is* a digression, after all). In truth, the absolute maximum rate for the critical flicker fusion rate is higher than 45hz. But it takes pretty high brightness and contrast levels for that to be a problem. I've forgotten the exact maximum but it's kind of academic. Computer displays don't get that bright. >I go further to note that 50 Hz. CRT displays typically flicker. Yes, and note that they are interlaced, giving a 25hz flicker rate! You're thinking as if they are non-interlaced. (The Encyc. Brit. discusses these European standard interlaced displays, too.) >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. As I indicate above, incorrect again. Sorry to gloat, but I'm still right on target. Actually, I love to gloat. :-) [ my comments about 120hz displays deleted ] > 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 ) ? The point is that it's nice to have a choice between the two, not have it made for you. The current Amiga design allows 200 line animation at 60hz, with flicker, or 400 line animation at 30 hz, with flicker dependent on image. (Yeah, you said something similar to this a little later, I know. I can't include *everything*). As to the relative values of temporal vs. spatial bandwidth in general, why, it depends on the application. Again, see the MIT Media Lab work. > 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. Oh, I agree. And this doesn't contradict anything I said. I already know that; you're acting like I said something dumb. So far everything you've tried to contradict has withstood your fire. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
doug@eris (Doug Merritt) (04/19/88)
Here's one that's short, sweet, and to the point: In article <3642@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: [ Bryan's comments about fF omitted ] >You are wholly incorrect. Inutition updates the pointer location at 60 >Hz regardless of whether the display is interlaced or not. So, no matter >what kind of deinterlacer you have , two feild store, or one feild >store, the pointer will break up. So...Bryan may have gotten confused about the issue of the Intuition pointer itself breaking up. As I said before, that's a nice counterexample of a situation that simply cannot be effectively deinterlaced; you'll always get inappropriate breakup. But note that you're still ignoring all of the *other* types of cases where Bryan's comments are still to the point. For *some* applications (both existing *and* written just for a flicker fixer), fF *could* be improved upon. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
doug@eris (Doug Merritt) (04/19/88)
In article <2839@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > Someone had concluded that in order to remove "jitter" [ ... ] > it would be necessary to interpolate intermediate > fields using specialized hardware. Note however, that since the frame > rate is so high, the "jitter" will be imperceptable and at any given > time two full fields will appear to be displayed at once with no > flicker. 1) Let's not get into the "jitter" vs. "flicker" terminology that Bryan suggested. Although I disagree (because I don't see how they differ), I don't think it's important to pursue. 2) Flicker is not equivalent to motion jerkiness. My comments about field interpolation applied to motion jerkiness. Your comments above apply to flicker (jitter, whatever). We're talking about two different things. In regard to flicker/jitter, you're quite right. But that doesn't apply to smoothing true object motion. >Even though the images will in fact be moving in a stuttering > manner to the viewer it will appear as smooth motion. Whether this statement is true or not depends purely on the speed of object motion versus the object redraw time (which is related to the frame rate, since you can't redraw an object coherently in less than one frame/field time). Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
harald@leo.UUCP ( Harald Milne) (04/19/88)
In article <8862@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > FLAME ON: > > And...it's interesting that this miniflame above ("go away") came from > someone who seems to have a great deal of difficulty understanding the > subject at hand, based on his poorly thought-out rebuttals that Bryan > and I dealt with explicitly already. Perhaps he wishes we'd stop talking > about a subject that makes his brain hurt from the strain of thinking > about it. Thanks a lot Doug. This from somebody crying out for help on the subject, which was when and why I joined this frackus. I came in when you were initially locking horns with Byran. Remember? Now suddenly you know it all. Ever heard of net propagation? I understand your taking exception to my posting, more on that below. > For instance, just a couple of postings ago Harald *implies* (my > interpretation of his posting) that the problem of images breaking up > is an optical illusion that wouldn't occur if viewed in slow motion on > video tape. That was a joke, which should have been obvious, but I guess I'm so obscure, I must include smileys for the rest of us. Not an optical illusion. I wanted proof. I cried for that in 3 postings. What better proof than the "smoking gun". I have NEVER seen any problem using FF now for 2 months. Now all of a sudden, Byran starts saying FF is flawed, but I have never seen any such flaw. What would you think? My reference to frame by frame VCR's, was a very inside joke, since as a videophile, I can't stand flaws in video. I can't stand VHS, I can't stand anything short of a LaserDisk or better. The joke is, FF has NOTHING to do with Amiga video, only the monitor. That's another problem, all I care about is that the Amiga video is pure and clean. I also became alarmed about talk of FF being flawed, since I have never seen it. Wouldn't you? > This demonstrates very thoroughly how little Harald understands > about either the problem, which we've analyzed in painstaking detail, or > probably human perception, too. I presume he *implied* this point, by asking > a question, rather than saying it directly, in order to put the burden > of proof on Bryan, knowing he (Harald) was on thin ice. We're all skating on thin ice, since all concerned have made incorrect statements at one point or another. That includes you and Byran. > No big deal, he's not required to be intelligent or well informed or > to thoroughly read our postings that would help remedy the latter lacks. > Until he tells Bryan to shut up. At which point I take strong exception. > > FLAME OFF. Fine. As far I was concerned, without proof Byran was talking through his hat. My mindset was very simple. (If you don't know what mindset is, you will after reading this) Once again, somebody was badmouthing the Amiga. Ok, you are entitled to your opinion. My response was simply prove it. That's all. So now I get flamed, but nobody has supplied any proof. That's nice. I don't have the time to lay around all day and read news. I work for a living, I have deadlines, I just was trying to help. Thanks for telling me to get F*CKED. You asked. > > Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) > or ucbvax!unisoft!certes!doug And now to why I am bothering to post this at all. First off, I owe Byran an apology. Sorry Byran, but I had to know for sure where you were coming from. Now on to what I learned since uunet started choking the chicken for 4 days. Since uunet was down, and we (ccicpg) had no news feed, I decided call the local BBS's. The first time I have done so in 6 months. I called 77AMIGA (that's (714-772-6442)) and saw a hot demo being raved about from West Germany. It was called INTROS.ARC. A very NICE demo, fantastic music scores, excellent graphics. This was the "smoking gun" demo I pleaded for. This demo makes the flaw in FF VERY apparent. It has a fantastic horizontally scrolling starfield. This appears to make to make the FF defect obvious. The interesting thing is, unlike what Byran said, it takes considerably LESS motion than 1 pixel per 30/sec. Every Amiga demo I have seen doesn't have this kind of motion. Any experts care to explain this one? -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
hedley@cbmvax.UUCP (Hedley Davis) (04/19/88)
In article <8929@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: >Here's one that's short, sweet, and to the point: > > [ Various comments about intution pointer always breaking up deleted ] > >But note that you're still ignoring all of the *other* types of >cases where Bryan's comments are still to the point. For *some* >applications (both existing *and* written just for a flicker fixer), >fF *could* be improved upon. > Yes this could have been done. It would have required twice the ram, and cmos static 32kx8 ram is not cheap. This seems like a classic example of a loss occuring due to financial constraints. I've developed the A2024 1008x800 monitor for Commodore. This also has a deinterlacing feature allowing you to run it like a flicker fixer. It reacts just like the existing flickerfixer and not in the way you would like. Its a shame we didn't have this net-war/discussion about eight months ago, because these aspects of the design are frozen. So, you can see one motivation behind my pressing for accurate protrail of the situtuation ( 'could be improved' as opposed to 'inherently flawed'). We are working on newer better stuff. Your comments, however flamed, will naturally enter into our list of considerations for futures. Hedley
farren@gethen.UUCP (Michael J. Farren) (04/20/88)
In article <3641@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: >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. I had the job, about three years ago, of evaluating a Thompson CSF computer system for the purpose of deciding whether a port of an existing software product to the system would be feasible. This was a French system, and came complete with a 50Hz PAL monitor. When I started to do the evaluation, I noticed extreme flicker, enough to give me a severe headache. Normally, I am NOT sensitive to flicker - I run an interlaced display on a standard Sony KV1311CR with no problems at all. So, I suspected that there might be something else going on. I turned off the lights in the office, and presto, NO flicker. My supposition was, and is, that the 60Hz strobe of the flourescent lighting was interacting with the 50Hz screen update on a low-persistance monitor, producing "beat" variations in the light input to my eyes. So, I would suspect that your "typical" display problems are simply due to the use of flourescent lighting in your workplace. Go to an entirely incandescent lighting system, and the flicker will likely be reduced to a quite acceptable level. BTW - this is an example of "true" flicker - changes in the light output of the _entire_ display, rather than the localized changes that are annoying in an interlaced display. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
doug@eris (Doug Merritt) (04/20/88)
In article <2984@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > First off, I owe Byran an apology. Sorry Byran, but I had to know for >sure where you were coming from. Thanks for apologizing to him. Since my only motivation for flaming was because of your rude comment to him, I hereby retract all of my flames. Other emotional details of our respective postings likely don't matter now. But in particular, you're right, I'm not an expert on the subject; sorry for acting supercilious. > This demo makes the flaw in FF VERY apparent. It has a fantastic >horizontally scrolling starfield. This appears to make to make the FF >defect obvious. Good; now we all agree. >The interesting thing is, unlike what Byran said, it takes >considerably LESS motion than 1 pixel per 30/sec. Every Amiga demo I have >seen doesn't have this kind of motion. > Any experts care to explain this one? The more information you can provide, the easier it would be to explain. I'm not sure I understand exactly what the phenomenon is that gives rise to your question. Could you describe this in more detail? Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
doug@eris (Doug Merritt) (04/20/88)
In article <3655@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: >We are working on newer better stuff. Your comments, however flamed, >will naturally enter into our list of considerations for futures. That's nice to hear! And, given the flame level, more than I would have expected. Thanks! [ my comments about an improved fF deleted ] >Yes this could have been done. It would have required twice the ram, Good point. How about a design that allows you to populate either just the basic memory, or twice as much for the improvement? As to the comment (deleted for brevity) about it being too bad that this didn't come up while you guys were still in the design stage, well, that *is* unfortunate. Maybe you could think of some way of discussing possible design tradeoffs on the net, without compromising company security and like policies? Perhaps by having some developer you trust bring it up for discussion, without it being Official Commodore Design Business? Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
hedley@cbmvax.UUCP (Hedley Davis) (04/20/88)
In article <8928@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: > >No. "happen to swap" isn't right...I'm claiming that anything that >animates a full 400 lines of detail at 30hz (which some people certainly >do!) is already swapping on the correct field, and that *this* is >what fF breaks. > What would happen if someone happened to swap just before odd feilds were displayed, but the fF swaps display buffers on even feilds ? ( Granted, this may seem odd, but not unlikely ). > >>I go further to note that 50 Hz. CRT displays typically flicker. > >Yes, and note that they are interlaced, giving a 25hz flicker rate! >You're thinking as if they are non-interlaced. (The Encyc. Brit. discusses >these European standard interlaced displays, too.) > Not always. In fact, for purposes of this discussion, I was thinking specifically about non-interlaced 50 hz displays. We build 'em for europe. They *are* bright enough to flicker and they *do* flicker. It is especially bad nowadays because everyone wants their whites to be 'paper white'. This means bright white, not light grey. Ask some people who have lived here, and then worked in europe for a while using 50 hz machines. ( This is unfair, because I have quite a few such people within a few feet of my desk who all agree that 50 Hz does flicker. ). Hedley
doug@eris (Doug Merritt) (04/21/88)
In article <3659@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: >specifically about non-interlaced 50 hz displays. We build 'em for >europe. They *are* bright enough to flicker and they *do* flicker. That's interesting. I didn't think they were bright enough. So, that raises the question, what *is* the absolute maximum critical flicker fusion rate under worst case conditions with contrast and brightness? Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
doug@eris (Doug Merritt) (04/21/88)
In article <884@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >and is, that the 60Hz strobe of the flourescent lighting was interacting >with the 50Hz screen update on a low-persistance monitor, producing >"beat" variations in the light input to my eyes. [ ... ] >BTW - this is an example of "true" flicker - changes in the light >output of the _entire_ display, rather than the localized changes >that are annoying in an interlaced display. That's interesting, since it implies that any field rate that's not synchronized to flourescent light frequency (equals line freq.) will have flicker problems. If the beat frequency is low enough, the field rate could be 2000 fields per second and you'd have flicker. Hmmmm... On the other hand, flourescent lights in *Europe* are 50hz, since that's their line frequency. So a 50hz noninterlaced display in Europe should not have a beat frequency problem with flourescent lights, right? And yet Hedley said that it was in Europe that the problem was observed. Strange. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
harald@leo.UUCP ( Harald Milne) (04/21/88)
In article <8928@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > But to return to the *original* point: simply that flickerFixer would > work better if it *only* merged the odd and even scan fields of a > single frame. I'm going to base the solution on the following presumptions: 1) When the Amiga powers up, to the day it dies, the stream of video information is NEVER interrupted. There is no flipping of fields for ANY reason. 2) As Bryan pointed out and as I suspected, FF only stores 2 fields of video information. (Odd and Even) 3) Somehow, if it is possible to detect (Hedley I need help on this) the start of a video frame, be it derived or otherwise, point to point wiring of the motherboard, glue logic, I don't care. We need to know the start of a video frame to do this correctly. (Although I have one other method to do it otherwise) 4) Buffering 2 video frames will solve ALL problems, no software intervention needed. A hardware solution. If I am wrong on any of these points, please let me know. It is very important that these presumptions are correct!!!!! The solution: (This would be a modification to the existing FF) 1) First, you have to double the storage to 2 full video frames. That's easy. Piggy back an extra set of rams, leave the chip selects free. Next, divide by 2 the select via a flip flop, feed the rams. Viola! Dual frame storage. 2) Take the derived frame start signal, use it to properly select the rams to video frames. This is the best and simple solution. If my presumtions are correct, I will implement this and post the modififaction. I can't stand flaws. If I am correct, this is a simple and easy fix. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
harald@leo.UUCP ( Harald Milne) (04/21/88)
In article <869@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: > In article <2972@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > >> Flicker: A perceived INTERMITTENCE in an ENTIRE image, as in successive > >> frames interleaved with intervals of 'darkness' (= absence of image). > > > > For us normal Amiga types, this is called "Non interlaced" > >Where alternate "half frames" are absent. That gives us the lines without > >information in non interlaced modes. > > This is not what happens at all. Non-interlaced mode does NOT have > "lines without information", and alternate half-frames are NOT absent. I was responding in the context of the original posting. If you don't believe me, record Amiga video in Interlace and Non-Interlace. Interlace will look fine, where Non-Interlace will look like sh*t. There is information absent. In the mentality of FF users, Non-Interlaced video appears complete, since FF fills this absence of non-existant information with duplicate data. You have to see FF in Non-Interlaced mode to see what I am talking about. The display is solid and "Pseudo Filled". > The difference is simply that in non-interlace, the lines are displayed > in the same position on the screen each 60th of a second. Correct. But there is information missing. The lines that aren't there, obviously are missing. This is not a complete NTSC display. > What you get > are 60 screens per second, each 200 lines tall. In interlace mode, every > other half-frame is displayed on the screen such that it falls between > the lines of the preceding half-frame. What falls in between is the missing information in Non-Interlaced mode. > Thus, you get a total of only > 30 screens per second, each 400 lines tall. There are no "lines without > information" in either mode. To put it in better terminology, you get 30 video frames a second. In Non-Interlace mode, you get 60 duplicate "even" fields. In Interlaced mode, you get "odd and even" fields. The bottom line is you get more information in Interlaced mode. Did anything I said make sense? If it didn't, let me know. I'll try again. Video displays can get terribly confusing. > -- > Michael J. Farren | "INVESTIGATE your point of view, don't just > {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate > unisoft!gethen!farren | it. You may want to change your mind someday." > gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
farren@gethen.UUCP (Michael J. Farren) (04/22/88)
In article <2988@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: >In article <869@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: >> This is not what happens at all. Non-interlaced mode does NOT have >> "lines without information", and alternate half-frames are NOT absent. > > I was responding in the context of the original posting. Well, I don't care about that context a whit - the statement that there is "information missing" in non-interlaced mode is flat incorrect, regardless of context. While it might be hidden, it is NOT missing. Let me put this another way: in interlaced mode, you are trading off the ability to update the display 60 times per second for the ability to put more lines on the screen. There are 60 fields worth of information sent to the monitor each second, in either mode, and no information is lost. Alternate half-frames are not lost, they are simply displayed in the same space as the other half-frames. > If you don't believe me, record Amiga video in Interlace and >Non-Interlace. Interlace will look fine, where Non-Interlace will look like >sh*t. There is information absent. No. There is NO INFORMATION ABSENT, except for one bit - the slight difference in timing between even and odd fields. Vertical sync timing differs between the two, and that is the ONLY difference. Perhaps some VCRs require the timing change, but the funny thing is that my own recordings of non-interlaced displays on a cheapo VCR look just fine. Maybe Beta VCR's just can't hack it :-) >Video displays can get terribly confusing. Yes, they can. I've found this out by working with them for almost fifteen years now, including several years designing them. Don't try and teach your grandma to suck eggs, eh? -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
doug@eris (Doug Merritt) (04/23/88)
In article <2988@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: >In article <869@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: >> This is not what happens at all. Non-interlaced mode does NOT have >> "lines without information", and alternate half-frames are NOT absent. > If you don't believe me, record Amiga video in Interlace and >Non-Interlace. Interlace will look fine, where Non-Interlace will look like >sh*t. There is information absent. I'm not sure I understand this; it seems strange. My understanding is that both the Amiga's interlaced *and* the non-interlaced video are fully NTSC compatible, meaning that the video signal always sends first a field of odd lines (starting at line 1), then a field of odd lines (starting at line 2). If you look at any given field, you will see that half the lines are missing...they won't be there until the next field. The only difference between interlaced and non-interlaced Amiga video is that in the latter case, the odd fields are a duplicate of the even fields, while in the former (interlaced) case, they are new information. Am I incorrect? If this is right, then the comment about recording Amiga video doesn't make sense...the recording on an NTSC video recorder should look exactly identical to the original Amiga display (assuming a normal, non-fF display). Or are you talking about something that *fF* does in non-interlaced mode, that has some different effect than an Amiga that doesn't have fF at all??? Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
harald@leo.UUCP ( Harald Milne) (04/23/88)
In article <9101@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > In article <2988@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > >In article <869@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: > >> This is not what happens at all. Non-interlaced mode does NOT have > >> "lines without information", and alternate half-frames are NOT absent. > > If you don't believe me, record Amiga video in Interlace and > >Non-Interlace. Interlace will look fine, where Non-Interlace will look like > >sh*t. There is information absent. > > I'm not sure I understand this; it seems strange. My understanding is > that both the Amiga's interlaced *and* the non-interlaced video are > fully NTSC compatible, meaning that the video signal always sends first > a field of odd lines (starting at line 1), then a field of odd lines > (starting at line 2). No, NTSC requires interlace and odd and even fields. Non-interlaced, while recordable on a VCR, is not the true NTSC standard. It HAS to be interlaced. This is getting hard to explain. The non-interlaced display in your terminology, starts at line 0, on every field. Forever. Call this the even fields. The odd fields are never present. That's the difference between interlaced and non-interlaced. Take a 640x400 interlaced display versus a 640X200 non-interlaced display. While both displays take the same space on the monitor, the difference between the two is alternate lines (or where there should be lines) are missing in the non-interlaced display. That's why you get 50 lines of text instead of 25, you have more lines to play with in an interlaced display. It's also the difference in information that I am talking about. > If you look at any given field, you will see > that half the lines are missing...they won't be there until the next > field. Only true for an interlaced display. A non-interlaced display wil never get the lines that are missing. It's always the same lines. (or the lack of them) > The only difference between interlaced and non-interlaced Amiga > video is that in the latter case, the odd fields are a duplicate > of the even fields, while in the former (interlaced) case, they > are new information. Yes, correct! > Am I incorrect? If this is right, then the comment about recording > Amiga video doesn't make sense...the recording on an NTSC video > recorder should look exactly identical to the original Amiga display > (assuming a normal, non-fF display). Again, correct. In the sense of what you record, you play back. But again, non-interlace is not a true NTSC format, half the information is missing. > Or are you talking about something that *fF* does in non-interlaced > mode, that has some different effect than an Amiga that doesn't > have fF at all??? No, not at all. This discussion has nothing to do with FF. I'm just talking about Amiga video. Wow, what a difficult concept to describe! Can anybody help me? I guess pictures would help. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
haitex@pnet01.cts.com (Wade Bickel) (04/24/88)
harald@leo.UUCP ( Harald Milne) writes: >In article <869@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes: >> Thus, you get a total of only >> 30 screens per second, each 400 lines tall. There are no "lines without >> information" in either mode. > > To put it in better terminology, you get 30 video frames a second. >In Non-Interlace mode, you get 60 duplicate "even" fields. In Interlaced mode, >you get "odd and even" fields. > > The bottom line is you get more information in Interlaced mode. > > Did anything I said make sense? If it didn't, let me know. I'll try Uggg... My video Prof. would have failed you both :^). In general I'd say Harald is correct, execpt that it is totally false to imply that there is more information in iterlaced mode. In interlaced mode the video beam is staggered 1/2 the line spacing on each successive video field and different information is displayed on each pass of the beam. Thus in interlaced mode you can sort of show 30 x 400 line displays per second as opposed to 60 x 200 lines, but the information transmition rate is still 12,000 lines per second in either case (no overscan considered). Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
dca@toylnd.UUCP (David C. Albrecht) (04/28/88)
In article <8777@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes: > >The FACT is, fF is the only product > >so far which addresses the flicker problem on the Amiga. [ ... ] > >apart much less objectionable than I find flicker. At least the fF people > >have made an attempt at a solution (which some people at least find useful). > > Although apparently well-intentioned, your critique of Bryan is not > to the point. Using your logic, no one on the net should ever claim that > any hardware or software product is flawed or has bugs, because > "at least they made an attempt at a solution". > > Many people will want to buy it anyway, since it is a partial solution. > Others, like me, will want to wait for a better product, even if it is > more expensive, and may take a while to become available. I don't disagree with analytic reviews. I do disagree with likening it to Pintos etc.. It was the tone that bugged me not the critical content. That fF is not perfect and that de-lacing can be done better is something the Amiga community wants to know. The world, however, is full of engineering tradeoffs. As it seems that better solutions would be more expensive (maybe quite a bit so) I think fF has made a very useful and reasonable example of such a tradeoff. Maybe you want a cadillac (BMW, Porche) I think more people want volkswagens (note how many more people bought the 500 than the 1000). The price is steep enough when you add the Multisync monitor already. I have a feeling that by the time a better solution comes out we will have A3000s with 68020s and flickerless graphic output modes. I'd rather save my nickels for that. David Albrecht