Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!caen!uwm.edu!ux1.cso.uiuc.edu!ernie!bazyar
From: bazyar@ernie (Jawaid Bazyar)
Newsgroups: comp.sys.apple2
Subject: Re: updating windows fast
Message-ID: <1991Feb15.212254.10659@ux1.cso.uiuc.edu>
Date: 15 Feb 91 21:22:54 GMT
References: <7566@crash.cts.com>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: bazyar@cs.uiuc.edu (Jawaid Bazyar)
Organization: Mutation Testing Facility, University of Illinois
Lines: 23

In article <7566@crash.cts.com> mdavis@pro-sol.cts.com (Morgan Davis) writes:
>In-Reply-To: message from acmfiu@serss0.fiu.edu
>
>The fastest way to scroll a window is to calculate the actual video RAM
>locations for its content, and then use a fast 65816 routine to do the
>pixel shifting on your own, preferably by using a table of offsets, or even
>faster, by generating code at runtime that moves pixels in an unrolled loop
>of load-store instructions.  Takes up a bit of RAM, but can result in
>blindingly fast scrolls, albeit against the rules.

  It's VERY against the rules.  I recommend to anyone out there writing
GS software to go by the book.  I heard a rumor (from a very reliable 
source) that someone is making a VGA quality graphics board for the GS.
Doing anything against the rules (i.e. not using QuickDraw for everything)
will, guaranteed, make your program incompatible with this board.
(This isn't the TurboRez, this is a new attempt by different people).


--
Jawaid Bazyar               | "I'm sure K&R have never heard of Mike." 
Senior/Computer Engineering |
bazyar@cs.uiuc.edu          | "That's okay. I'm sure Mike's never heard of K&R".
   Apple II Forever!        |  (discussion about Orca/C)