Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!portal!cup.portal.com!chad
From: chad@cup.portal.com (Chad The-Walrus Netzer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fast 2-D Scrolling Method Needed
Message-ID: <15513@cup.portal.com>
Date: 8 Mar 89 00:55:51 GMT
References: <112@dg.dg.com> <10871@well.UUCP> <113@dg.dg.com>
Organization: The Portal System (TM)
Lines: 48

In a previous article (Derek Bosch) writes:
)In article <10871@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)>	Well, you could try using 'tiles'.  That is, divide the virtual
)>screen up into X by Y cells, each of which are a fixed size.  When you have
)>your cells, you can represent your virtual screen as an array of bytes/words
)>arranged as X by Y.  Each element in the array serves as an index into the
)>array of cells you have created.  Thus, you can assemble your entire screen by
)>blitting smaller cells into it.
)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. 

	Well, for a scrolling screen, why not use the scrolling feature built
into the Amiga's hardware?  This way, when you are scrolling, you need
only fill/blit in the new areas as they are about to scroll onto the
screen (ie.  Tile method).  However, the scrolling itself is done by the
hardware, and will involve only a few pointer changes, rather than
repeatedly blitting whole bitmaps by just a few pixels (SLOW).
	The problems with this method are:
	- Integrating it with the Intuition environment.  It is not
impossible, but I don't know how important this is to your application.
	- Uses lots of memory.  But since ALL scrolling methods will
probably use lots of memory, you probably are prepared for this.  Things
like recopying memory sections and re-setting pointers will have to be
done, so that the bitmap doesn't 'creep' through memory (like a 'queue').
By allowing the hardware to scroll for you most of the time, and then
re-blitting the bitmap back into place each time it scrolls by 16 pixels (a
word) or so, you will reduce blitter usage by approximately 1/16th, and
improve its efficiency by operating solely on word boundaries.  Note:  For
smoothness, you will probably want to intercept the Blitter at the bottom
of the frame and NOT by using WaitTOF(), etc...  This will give you the
TRUE vertical retrace time to use the blitter when it is most efficient. 

	Keep in mind that using the hardware on this level could negate
the direct use of the Intuition and Graphpics libraries (but not
necessarily).  Decide what is important for your project.  Also, doing
this correctly does not mean you have to give up multi-tasking, just
manage your own displays more carefully.  A good knowledge of Intuition,
Graphics, and the Hardware is necessary.  You DEFINATELY need to read the
Hardware Manual's sections on Playfields, scrolling, and the Copper VERY
CAREFULLY!

	Hope this helps (and didn't discourage) you, and just ask if you
need more help/ideas.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
				Chad 'The_Walrus' Netzer -> AmigaManiac++
"Faster than a speeding Blitter..."