Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ucsdhub!jack!crash!pnet01!haitex From: haitex@pnet01.cts.com (Wade Bickel) Newsgroups: comp.sys.amiga.tech Subject: Re: Message from designer of FlickerFixer Message-ID: <3348@crash.cts.com> Date: 20 Aug 88 17:16:47 GMT Sender: news@crash.cts.com Organization: People-Net [pnet01], El Cajon CA Lines: 34 u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes: >Note: I un-cross posted this. > >This would be fixable *if* the Amiga matched the short and long frames >instead of ignoring them for *update* purposes. Things move between each >frame, whether long or short. The above example would be great if Ami >didn't change things between (for example) short[0] and long[1] as well as >between long[1] and short[2]. Several things are updated in screen memory This should not happen in a double buffered Interlaced display. I guess if you aren't buffering your output anything could happen. However, when you write into say, a 320x400 bitmap, that is exactly how it appears to the RastPort. No interleaving is recognized at this level. Assumedly, in an interlaced animation the animation program should make sure that both frames are given time to be shown. If not, why waste bandwidth using interlaced mode (ie for drawing), as those long frames will not be seen anyway. (Certainly we don't draw into the bitmap as it's being shown, or we're in rip city :^)). I sincerly doubt that what you describe actually happens. The Ami does change things between short[0] and long[1], but these are probably things in short[2] or long[3]! It's just bad programming if anything else happens (using INTERLACED output). 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.