🚀 go-pugleaf

rchampe@hubcap.UUCP (Richard Champeaux) writes:
>In article <8577@agate.BERKELEY.EDU>, doug@eris (Doug Merritt) writes:
>> 
>> To be more explicit, you could fix flicker by doing the following:
>> 	- get a half-frame of video from the Amiga (say the even lines)
>> 	- display it twice in the 1/30th of a second before the next
>> 	  half-frame (the odd lines) comes in.
>> 	- repeat on this next half-frame (now we're doing odd lines)
>> This gives 120hz interlaced, causing a 60hz flicker rate, above the
>> 40hz "critical flicker fusion rate", which perceptually eliminates flicker.
>
>     Could you explain this a little more, I not sure I follow what you're
>saying.  If you have a horizontal single pixle width line, it would be on the
>screen every other 1/60th of a second interval.  (I might be wrong but I
>think you meant that each half-frame comes in every 1/60th of a second).
>What I'm trying to ask is: no matter how many times you display a half frame
>before the next one comes in, won't that horizontal line still be on the screen
>only every other 1/60th of a second interval?
>

        I think Doug has the right idea, he was just not quite "explicit"
      enough.  Let me give it a try.

	First lets define some terms; A video "frame" consists of two
      "fields" which occupy alternating scan-lines of the display.  An
      interlaced picure is a "frame" consistings of two such fields.
      This terminoligy is standard in the video world so lets try to
      follow it to reduce future confusion.  In this discussion lets
      refer to these as the odd and even fields, and assume that odd
      fields come first (I can't remember if this is true or not).

	Now on to flickerfixing.  In the following example time is shown
      on the left in 60th sec.s.


	T = 0   :	Capture odd feild #1.

	T = 1   : 	Display odd field #1.  Capture even field #1.
      
        T = 1.5 :	Display even field #1.

	T = 2   :	Display odd field #1.  Capture odd feild #2.

	T = 2.5 :       Display even field #1.

	T = 3.0	:	Display odd field #2.  Capture even field #2

	T = 3.5 :	Display even field #2


		Etc....


	   Since this is all synchronis, it can probably be done with
	something less than 2 full field buffers, but these must buffer
	RGB data.  As I figure it you'd need about 2 megs of serially
	addressable memory, as opposed to RAM.  Of course I have not
	really sat down and calculated this recently so this figure
	may be off.  Also, an additionall 1/2 cycle of delay might
	be needed in the capturing of the fields, which would require
	slight adjustment to the description above.


						          Wade.


UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM