🚀 go-pugleaf

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.