Xref: utzoo comp.sys.amiga:21845 comp.sys.amiga.tech:1520 Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!rutgers!ucsd!ames!elroy!gryphon!crash!pnet01!haitex From: haitex@pnet01.cts.com (Wade Bickel) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: Message from designer of FlickerFixer Message-ID: <3318@crash.cts.com> Date: 16 Aug 88 09:16:39 GMT Sender: news@crash.cts.com Organization: People-Net [pnet01], El Cajon CA Lines: 36 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.