🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Fixing flicker, & future frame rate issues

#8495
From: Bryan Bayerdorffer
Date: Thu, 14 Apr 1988 21:00
35 lines
2883 bytes
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. :-)
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
Technical Details
Message-ID: <11253@ut-sally.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!im4u!ut-sally!gamera!bryan
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <3626@cbmvax.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!im4u!ut-sally!gamera!bryan
From: bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <11253@ut-sally.UUCP>
Date: 14 Apr 88 21:00:54 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <3626@cbmvax.UUCP>
Sender: news@ut-sally.UUCP
Reply-To: bryan@gamera.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 34
Spam-Content: High