Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!jarthur!petunia!news
From: araftis@polyslo.CalPoly.EDU (Alex Raftis)
Newsgroups: comp.sys.apple2
Subject: Re: More extended graphics on the IIgs
Message-ID: <279f4cb8.4684@petunia.CalPoly.EDU>
Date: 24 Jan 91 21:08:08 GMT
References: <1991Jan21.235524.1@gacvx1.gac.edu> <14955@smoke.brl.mil>
Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407
Lines: 30



In article <14955@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1991Jan21.235524.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes:
>>Ok... now I get the idea that ...
>> ...
>>
>
>I don't quite understand why you ask this.  The 3200-color demos manage to
>keep the SCBs updated (barely) faster than the scanning rate.  "Flicker"
>as you call it (usually called "tearing") would occur only if you couldn't
>update the SCBs fast enough.  Obviously if you set up a backing array for
>the SCB data, it could be rolled into the actual SCBs at a sufficient rate
>to keep up with display scanning.

Does it actaully take up _so_ much CPU time. I was hacking around with
some simple assembly, and I made a program to attempt to change the
color of pixel as the scan line went accross the screen. By the looks of
things, I could change things fast enough, but I had no way of timming
the updates, so the colors scrolled on the screen. Someone better at
assembly might be able to rig up some kind of timing to get this to
work, though I can't see how considering interrupts make software timers
un-reliable.



-- 
               -------------------------------------------------- 
                     Internet: araftis@polyslo.CalPoly.EDU
               America Online: xela      (Real Life: Alex Raftis)