Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!utah-gr!utah-cs!sunset.utah.edu!u-jmolse From: u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) Newsgroups: comp.sys.amiga.tech Subject: Re: Message from designer of FlickerFixer Message-ID: <5662@utah-cs.UUCP> Date: 18 Aug 88 06:00:09 GMT References: <3328@crash.cts.com> Sender: news@utah-cs.UUCP Reply-To: u-jmolse%sunset.utah.edu.UUCP@utah-cs.UUCP (John M. Olsen) Organization: University of Utah, Computer Science Dept. Lines: 73 Note: I un-cross posted this. haitex@pnet01.cts.com (Wade Bickel) writes: >u-jmolse%ug@utah-cs.UUCP (John M. Olsen) writes: >>> 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