🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Fixing flicker, & future frame rate issues

#8529
From: Bryan Bayerdorffer
Date: Wed, 13 Apr 1988 03:53
52 lines
4035 bytes
In article <8649@agate.BERKELEY.EDU> doug@eris.berkeley.edu (Doug Merritt) writes:
=-time (in 1/120 sec):    0  1  2  3  4  5  6  7  8  9 10 11 12
=-time (in 1/60 sec):     0     1     2     3     4     5     6
=-time (in 1/30 sec):     0           1           2           3
=-half-frame displayed:	   ...      1  2  1  2  3  4  3  4  etc
=-full-frame displayed:      ...      1  1  1  1  2  2  2  2  etc
=-
=-The "..." represents time spent gathering the first two half-frames
=-in the first 30th of a second, so that they can be displayed at a higher
=-rate than they were generated, in the next 30th of a second.
=-
=-This shows a full-frame being generated and displayed each 30th of
=-a second. But each half-frame is displayed twice within that interval
=-(e.g. half-frame number two appears twice in the first 30th sec).
=-It's true that you don't get a new set of two-half frames until a
=-full 30th of a second goes by, and that has second-order effects,
=-but the first order effect is simply a question of stroboscopic flicker,
=-which perceptually disappears around 40 to 45 hertz. Since you're
=-strobing half-frame two at 60 hertz, there's no stroboscopic flicker.
=-
	Aha, so you want to INTERLEAVE the two fields (heretofore 'half-
frames').  I suspected that this was what you meant, but I was being 
deliberately obtuse so I could act superior. :-)  Yes, this will work, but you
STILL have to buffer four fields to prevent breakup.  Therefore, all this might
buy you is...

=-The second-order effect is smoothness of motion. Consider times you've
=-seen a film/vcr played in slow motion. If it was filmed at the regular
=-rate, motion looks jerky in slow motion even though there's no stroboscopic
=-flicker. It's not the whole picture that looks jerky/flickery, as it
=-does at slow frame display rates, it's just the motion itself.
=-
	Now you're on track.  Your method would be smoother.  Except that as
the frame rate increases, the effect of double-shuttering decreases.  A double-
shuttered, 24 frame/sec film gives the eye 1/48th sec to fix the image.  A
properly working flickerFixer gives it slightly longer--1/30th sec.  Let's say,
for the sake of argument, that the image-fixing time of the eye is somewhere
around the perceptual stroboscopic threshhold (say that three times fast),
which you give as ~40Hz, i.e. 1/40th sec.  (1/40)/(1/30) = 1.33, so the fF video
is only 33% more jumpy than 'real motion,' assuming a linear relationship,
whereas un-double-shuttered film is 67% more jumpy.  Your method shows each
field for 1/120th second, which is 200% LESS jumpy than reality (no
existentialist humor, please).  This seems a little excessive, if the cost of
a 120Hz display is going to be about twice that of a 60Hz display, which is a
reasonable assumption.
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_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: <11227@ut-sally.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryan
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <8649@agate.BERKELEY.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryan
From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <11227@ut-sally.UUCP>
Date: 13 Apr 88 03:53:11 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <1367@hubcap.UUCP> <8649@agate.BERKELEY.EDU>
Sender: news@ut-sally.UUCP
Reply-To: bryan@mothra.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 52
Spam-Content: Negligible