🚀 go-pugleaf

Note: I un-cross posted this.

haitex@pnet01.cts.com (Wade Bickel) writes:

>u-jmolse%ug@utah-cs.UUCP (John M. Olsen) writes:
>> <FlickerFixer does the best it can>

>        Not so. ... 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]
>                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]

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 
and on the display every 60th of a second. :^(

>        Still, I cannot see the fF being accurately described as a
>de-interlacer.  It is a flickerFixer.  I think there is a difference.

I called it a de-interlacer simply because it takes an interlaced signal as
input and sends a non-interlaced output.  If this is wrong, and if anyone's 
shorts got in a bind because of this, I'm sorry. :^)

>        By definition an interlaced screen has a specifically matched Long
>and Short frame.

They may be matched, but things still move between each 1/60th sec frame, 
(or half frame, if you want to look at it that way) so anything that tries 
to join them in any way will have moving objects go schitzoid.

>>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.

TV runs at 30 Hz, displaying who halves of a single picture per 1/30 of a 
second.  The Amiga doesn't redisplay two halves of a single still picture, 
but draws whatever happens to be the most current stuff to draw.  Close, 
but not exactly the same.

>        My only point in all this is that one possible solution might be
>to speed up the frame rate of the Amiga.

Yup.  It would be great if we could have multisync way-hi-res output while
still being able to go back to (near) NTSC.

>                                                                    Wade.
>UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
>ARPA: crash!pnet01!haitex@nosc.mil

I guess with stereoscopics, you have to know which frame is which, and
only update at 30 Hz max.  I still have to give you a phone call about
adding stereo and LC shutter stuff to my game, Wade. :^)

 /|  |     /|||  /\|       | 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
	"...if cows ate plankton whales would die off." Randy Meyers