Path: utzoo!mnetor!uunet!cbmvax!hedley
From: hedley@cbmvax.UUCP (Hedley Davis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <3642@cbmvax.UUCP>
Date: 18 Apr 88 04:33:20 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <3626@cbmvax.UUCP> <11253@ut-sally.UUCP>
Reply-To: hedley@cbmvax.UUCP (Hedley Davis)
Organization: Commodore Technology, West Chester, PA
Lines: 61
Keywords: Point- Counterpoint

In article <11253@ut-sally.UUCP> bryan@gamera.cs.utexas.edu writes:
>In article <3626@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes:
>
>=-The FlickerFixer design is not flawed given the boundary values of the
>=-problem.  As was previously stated, ( by someone else whose .sig I've
>=-lost ), the information which comes from the amiga for adjacent lines is
>=-separated in time by 1/60 th of a second. In this time, animated objects
>=-have moved and therefore you have the 'split image' artifact that is
>=-being complained about.  True this artifact is not desirable, but the
>=-only solution is to change the in which the data is emitted from the
>=-amiga, IE software change.  The flickerfixer is totally software
>=-compatible, indeed from the perspective of the board, it has no ability
>=-to change the system software, and hence, fetch ordering of bitplane or
>=-sprite data. Given this constraint, its about the highest degree of
>=-functionality you can get.
>=-
>	What sort of logic is this?  Just because things moved in 1/60th
>second intervals will break up WITHOUT the flickerFixer doesn't excuse the
>fact that objects moved every *1/30th* second break up WITH fF.  For the
>nth time:  the problem is that fF displays two 200-line fields that DO NOT
>GO TOGETHER.  This is NEVER the case in the normal interlaced display,
>therefore software written to synch at 1/30th second will look right,
>whereas with fF it WILL NOT, if the rate of movement exceeds 1 pixel every
>1/30th second.  Am I not correct in stating that the mouse pointer is moved
>by the system every 1/30th second?  If this is true, then it should NEVER
>break up if two matched fields are always displayed together.  But it does!
>See:  I'm waving it at you right now!  I don't know how to make it any
>clearer. :-)
>

Did'ja ever see that famous Saturday Night Live imitation of the old
news segment 'Point/Counterpoint' ? The one where the Dan Ackroyd (sp?)
responds to the opening comments made by Jane Curtain with 'Jane,
you ignorant Slut !' ?

Bryan, you ignorant Scum !

You are wholly incorrect. Inutition updates the pointer location at 60
Hz regardless of whether the display is interlaced or not. So, no matter
what kind of deinterlacer you have , two feild store, or one feild
store, the pointer will break up.

Now, it is quite academic that this could be changed, but don't claim
my spam content is high when you haven't even got your facts down.

And don't go spouting off about the system being incorrect either.
The system updates the pointer at 60 hz on an interlaced display because
this splitting artifact does not show up without a flicker fixer.
Therefore, the display looks better because motion is better smoothed.

You always could request a new preferences setting to slow the system
pointer updates. :-)


Hedley

( I am presuming that you mistated your opening comments about 
things being moved 60 time a second breaking up without a flicker
fixer. If this is indeed you opinion, then you oughta try some
experimention. Look at the sprite, it looks ok without a flicker
fixer, right ? ).