Article View: comp.sys.amiga.tech
Article #8495Re: Fixing flicker, & future frame rate issues
From: Bryan Bayerdorffer
Date: Thu, 14 Apr 1988 21:00
Date: Thu, 14 Apr 1988 21:00
35 lines
2883 bytes
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!bryanReferences:
<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