papa@pollux.usc.edu (Marco Papa) (08/15/88)
Peter Selverstone, designer of FlickerFixer and with no access to Usenet, asked me to forward this. Enjoy. ------ Memo #20009 From: pselverstone Date: Sun, 7 Aug 88 00:06:04 EDT To: papa Message-Id: <memo.20009> Subject: Usenet message Marco, I'd appreciate it if you would post the following message to the Amiga group on Usenet if that is possible. haitex@pnet01.cts.com (Wade Bickel) writes: > ... Our 3D glasses will not work with either the FlickerFixer or > Long Perstistance monitors. > As I see it the problem is that the Amiga's refresh rate is too slow. >The reasons for this are obvious; We live in a 60hz country. In Europe >things are even worse with PAL, which runs at only 50hz (or is it 48?). > The FlickerFixer is a half-azzed attempt to double buffer the display, >which I think is junk. But I can understand their reasoning. It does >elimate the flicker on interlaced images, and uses (I assume) only about 1/3rd >the memory it would have taken to do it right. And of course, it works with >a multi-sync monitor at 76hz. But I really don't like the way objects in >motion split, and especially the inablity to by-pass the thing. > What I think C= should do is support a 76hz mode. This would mean >that with a multi-sync monitor you would acchieve a 38hz flicker rate between >the short and long frames of interlaced images, which I doubt would be >perceptable in any but the worst of circumstances. It seems to me that individuals associated with companies doing business in the Amiga market are under a special obligation to provide accurate information to the Amiga community. The propagation of inaccurate information about another company's product is foolish. It causes users to question the technical competence of the originator and his employer. People have a lot of fun with disclaimers. Here is a case where their purpose is clear. I note that there was none on this message. Haitex would be well advised to require them. This is of some consolation to me as I designed flicker fixer and much of the discussion that I have seen on Usenet (I've only caught bits and pieces) seems to be based on a misconception of the manner in which it operates. I am not currently on Usenet. If people are interested in information on flicker fixer I am quite active on most of the commercial services. Peter Selverstone Bix:pselverstone Plink:pselverst CIS:72527,2652 ------ -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
haitex@pnet01.cts.com (Wade Bickel) (08/16/88)
My appologies to Peter Selverstone.
I did not intend to say that the flicker fixer itself is poorly
designed, and clearly miss-worded my sentance. What I meant to say was
that the way (I think) it works is a cludge. The cludge is needed to solve
a problem that is otherwise unreasonably expensive to correct.
The flicker fixer clearly does what it was designed to do and in that
respect is a fine product. However I stand by the point that IDEALLY it
should not be mixing mis-matched fields (which I can definitly see it doing).
As stated before I think that given the cost of RAM the manner in which the
flicker fixer does function is reasonable. Who would buy it if it cost
a $1000 or more?
Am I mistaken it beleiving that what you've done is to buffer each
video field (using video industry terminology) and then combine it with the
subsequent field to form a frame (de-interlaced display). Given this
methodology doesn't that mean that every other display update contains a
Frame composed of mis-matched feilds? If I am mistaken about this what is
the reason for the splitting up of images, most clearly seen by moveing the
mouse angularly across the screen at a rapid rate?
Again, I am sorry for having implied that the design of the fF was
poor, which it is not.
Sincerly,
Wade W. Bickel
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) (08/17/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >The cludge is needed to solve >a problem that is otherwise unreasonably expensive to correct. >...However I stand by the point that IDEALLY it >should not be mixing mis-matched fields (which I can definitly see it doing). >...buffer each >video field (using video industry terminology) and then combine it with the >subsequent field to form a frame (de-interlaced display). Given this >methodology doesn't that mean that every other display update contains a >Frame composed of mis-matched feilds? > Wade W. Bickel > >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex >ARPA: crash!pnet01!haitex@nosc.mil >INET: haitex@pnet01.CTS.COM >Opionions expressed are mine, and not necessarily those of my employer. This came up before, but I think that much of the discussion was in Email (for a change :^). When the machine is modifying the display at 60 Hz, like redrawing a moving mouse pointer, there are no two correctly matched fields to display that will not cause split images, and hence the Flicker- fixer does the absolute best possible thing until the system forces all software to update at a maximum of 30 Hz, which would be a Bad Thing. Nobody likes having their animation speed cut in half. The designers worked with what they had, and did the best they could. To properly de-interlace an NTSC signal, you need to be able to tell which pair to match, but only if they are meant to be matched, which they currently are not on the Amiga. Under the current system, every pair of adjacent frames is technically mis-matched, but you only notice when things move. It's a common problem for someone familiar with how TV NTSC works to see a computer that sends an NTSC signal, and assume that the formats are similar. You should know better than to trust a standard. :^) /| | /||| /\| | John M. Olsen, 1547 Jamestown Drive \|()|\|\_ |||. \/|/)@|\_ | Salt Lake City, UT 84121-2051 | u-jmolse%ug@cs.utah.edu or ...!utah-cs!utah-ug!u-jmolse "I'd give my right arm to be ambidexterous."
haitex@pnet01.cts.com (Wade Bickel) (08/17/88)
u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes: >This came up before, but I think that much of the discussion was in Email >(for a change :^). When the machine is modifying the display at 60 Hz, >like redrawing a moving mouse pointer, there are no two correctly matched >fields to display that will not cause split images, and hence the Flicker- >fixer does the absolute best possible thing until the system forces all >software to update at a maximum of 30 Hz, which would be a Bad Thing. >Nobody likes having their animation speed cut in half. The designers >worked with what they had, and did the best they could. Not so. What you could do is to buffer a full 2 fields and show them on both screen updates. Example: Time (60th/secs) Amiga Displays Buffered video output ------------------- ------------------ --------------------------------- 0 Shortframe[0] undefined 1 Longframe[1] undefined 2 Shortrame[2] Shortframe[0] + LongFrame[1] 3 Longframe[3] Shortframe[0] + Longframe[1] 4 Shortframe[4] Shortframe[2] + Longframe[3] 5 Longframe[5] Shortframe[2] + Longframe[3] 6 Shortframe[6] Shortframe[4] + Longframe[5] as compared to what the fF generates 3 Longframe[3] Shortframe[2] + Longframe[3] 4 Shortframe[4] Longframe[3] + Shorframe[4] 5 Longframe[5] Shortframe[4] + Longframe[5] As you can see, this does not impose any slow down on the actual data rate of the CRT. It does however require aprox. twice the ram, and this is why the fF does things the way it does. With RAM chips as expensive as they are cost is a definite design criterium, and a legitimate one at that. Still, I cannot see the fF being accurately described as a de-interlacer. It is a flickerFixer. I think there is a difference. > >To properly de-interlace an NTSC signal, you need to be able to tell which >pair to match, but only if they are meant to be matched, which they >currently are not on the Amiga. Under the current system, every pair of >adjacent frames is technically mis-matched, but you only notice when things >move. By definition an interlaced screen has a specifically matched Long and Short frame. Admittedly a non-interlaced screen has no such property. It is interlaced screens we are discussing when talking about the fF? No? > >It's a common problem for someone familiar with how TV NTSC works to see >a computer that sends an NTSC signal, and assume that the formats are >similar. You should know better than to trust a standard. :^) > When examining the Amiga display system it is clear that it was designed to emulate NTSC video, which has it's positive and negative points. The formats are almost IDENTICAL. Clearly the intelaced mode coresponds directly to normal NTSC video. My only point in all this is that one possible solution might be to speed up the frame rate of the Amiga. If the A3000 were to have the ability to be put in a special 76hz mode, it could be used with a Multi- Sync monitor and would provide a 38hz interlaced mode, whicl would probably appear flickerless to over 40% of the population in normal viewing conditions (supposedly at 40hz 50% of the pop notices no flicker, the visual LD50 :^)). What would be even better would be adjustability. Of course, I think refreshed displays are a soon-to-be thing of the past (a couple of years), so new display issues will probably hit us before the A3000 does :^). In the meantime, imperfect as it is, the flickerFixer is the only game in town. Thanks Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM Opionions expressed are mine, and not necessarily those of my employer.
keithd@cadovax.UUCP (Keith Doyle) (08/19/88)
In article <3328@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > By definition an interlaced screen has a specifically matched Long >and Short frame. Admittedly a non-interlaced screen has no such property. Ah, I have a question about this terminology. From what I remember from my video days, is that a "Frame" is made up of two "Fields", even and odd, and they're both the same size, 262-1/2 lines. One of the fields starts 1/2 line out of phase with the other. How does that translate to your use of "short" and "long" frame terminology? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jesup@cbmvax.UUCP (Randell Jesup) (08/19/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > The flicker fixer clearly does what it was designed to do and in that >respect is a fine product. However I stand by the point that IDEALLY it >should not be mixing mis-matched fields (which I can definitly see it doing). ... > Am I mistaken it beleiving that what you've done is to buffer each >video field (using video industry terminology) and then combine it with the >subsequent field to form a frame (de-interlaced display). Given this >methodology doesn't that mean that every other display update contains a >Frame composed of mis-matched feilds? If I am mistaken about this what is >the reason for the splitting up of images, most clearly seen by moveing the >mouse angularly across the screen at a rapid rate? In reality, there are 4 'fields' per 'frame', but for our purposes we can act as if there are 2, Long Field and Short Field. Now, when displaying interlaced video, we alternate bewteen these, each displaying every other line. If an object is moving at least 1 pixel/field, it will have moved on every field relative to the last field. This is what is confusing you. ANY two fields with a moving object will NOT show a single object, but will show the same object in two positions. Usually, these are only a few pixels apart, so it looks like "fuzz" on the left and right edges. Remember these two images are on every other line. The two images are sampled at different times, so the object is in different positions. This is the equivalent of beam collision when writing data to the screen when the beam is reading it (though not exactly the same, as there's no way to double-buffer). So, to reiterate, there is NO way to get rid of the moving-object effect when de-interlacing interlaced video. NONE. The reason you usually don't notice is that your brain sees them as two pictures of the same object at different times, and tracks it as a moving object. By the time the next field comes around, the image has mostly faded (the cause of interlace flicker), so the brain doesn't see the two offset images at the same time. After being deinterlaced, they appear simultaneously, which is very obvious to the brain. > Again, I am sorry for having implied that the design of the fF was >poor, which it is not. > > Wade W. Bickel -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jdow@gryphon.CTS.COM (J. Dow) (08/21/88)
In article <3318@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >My appologies to Peter Selverstone. > > > I did not intend to say that the flicker fixer itself is poorly >designed, and clearly miss-worded my sentance. What I meant to say was >that the way (I think) it works is a cludge. The cludge is needed to solve >a problem that is otherwise unreasonably expensive to correct. > > The flicker fixer clearly does what it was designed to do and in that >respect is a fine product. However I stand by the point that IDEALLY it >should not be mixing mis-matched fields (which I can definitly see it doing). >As stated before I think that given the cost of RAM the manner in which the >flicker fixer does function is reasonable. Who would buy it if it cost >a $1000 or more? > > Am I mistaken it beleiving that what you've done is to buffer each >video field (using video industry terminology) and then combine it with the >subsequent field to form a frame (de-interlaced display). Given this >methodology doesn't that mean that every other display update contains a >Frame composed of mis-matched feilds? If I am mistaken about this what is >the reason for the splitting up of images, most clearly seen by moveing the >mouse angularly across the screen at a rapid rate? > > Again, I am sorry for having implied that the design of the fF was >poor, which it is not. > Perhaps you would care to detail a correct design? With moving pictures you have two frames in succession - ANY two frames - that cannot possibly match perfectly unless the animation is done wrong. (Assuming you are talking about an interlaced animation. I have not noticed any particular problem with 200 line animations.) You get this effect on standard TV as well as the Amiga. Correcting it requires a great deal of video processing, I am afraid. For the price I do not think it is possible to do any significant bit better than the FlickerFixer. (I just wish it had three times the memory so that it could display a decently digitized TV picture overlayed genlock style on the Amiga graphics. (Then for REALLY nice TV I might just let screenblanker blank the Amiga screen and ..... Just think - Rambo with no flicker <gag - choke> -make that Worf with no flicker.) > Sincerly, > > > Wade W. Bickel > > >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex >ARPA: crash!pnet01!haitex@nosc.mil >INET: haitex@pnet01.CTS.COM >Opionions expressed are mine, and not necessarily those of my employer. Equally sincerely, Joanne B. Dow -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.