🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #9567

Re: Message from designer of FlickerFixer

#9567
From: John M. Olsen
Date: Sun, 21 Aug 1988 17:14
46 lines
3256 bytes
In article <3348@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes:
<u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes:
<>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 
<
<        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 :^)).

Interlaced mode and updating at 60 Hz is still a winner because it tricks
our brains into seeing what was meant instead of what is really drawn.
You will see the odd scans of screen n, the even scans of screen n+1, and
so on, and your brain is pretty good at interpolating the "missing" half.

I guess you must conclude by your argument that the Amiga was built wrong.
I personally like the *ability* to redraw at 60 Hz, whether used or not.
At least we now know it wasn't the fault of the designer of FlickerFixer.
The Amiga doesn't buffer rastport info, so it draws whatever happens to be
there when it wants to show a particular pixel, no matter whether it's an
interlaced or noninterlaced display.  It's up to the software to decide when
to draw what.

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

Move the pointer around quickly on an interlaced screen.  Each time it is
drawn, you will see either odd or even scans drawn, but *never* both at the
same location as long as the mouse is moving.  QED.  (If you have a hard
time seeing this, you could record it on a VCR and single frame it.)

<                                                        Thanks,
<                                                                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
Technical Details
Message-ID: <5668@utah-cs.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!attcan!uunet!husc6!mailrus!utah-gr!utah-cs!sunset.utah.edu!u-jmolse
References: <3348@crash.cts.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!attcan!uunet!husc6!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: <5668@utah-cs.UUCP>
Date: 21 Aug 88 17:14:18 GMT
References: <3348@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: 46