Xref: utzoo comp.sys.amiga.tech:4072 comp.sys.amiga:30408
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!apple!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga.tech,comp.sys.amiga
Subject: Re: Fast 2-D Scrolling Method Needed
Message-ID: <10921@well.UUCP>
Date: 9 Mar 89 09:22:15 GMT
References: <112@dg.dg.com> <10871@well.UUCP> <113@dg.dg.com>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Surf Nazis Must Die!
Lines: 19
Quote: "Logic is wreath of pretty flowers, which smell *bad*."  -- Spock

In article <113@dg.dg.com> bosch@dg.UUCP (Derek Bosch) writes:
>Tiles sound like the way to go.  Which way is faster though?  1)  Create a new
>bitmap by scrolling portions of the screen that stay on the screen, and
>blitting in only the new portions of the screen.  2)  Create a totally new
>bitmap by blitting in each cell, each time you update the screen.  
>
	If you're doing hardware scrolling, #1 is the winning method.  If,
however, you're scrolling the image in a "window", and you're not faking it
with dual playfield, then it's a toss-up.

	A nice rule of thumb is to try to draw a given pixel as few times as
possible.  Computations and hardware scrolling are cheap.  Drawing bits is
the expensive part, so the fewer times you draw bits, the better.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor