Fast 2-D Scrolling Method Needed

Using tiles for a scrolling screen works well. If you look carefully at
Faery Tale, you will see that it actually uses a two-level tile system. At
a guess (I'm not in front of my Amiga to count), it uses tiles composed of
4 x 4 subtiles, each of which is about 16 x 16 pixels. It must have been quite
a chore getting the subtiles set up so that everything goes together properly,
and still looks good. You can see the tile size most easily by looking at
some of the floor tiles - the part that isn't shadowed is a basic subtile.

--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg

Hmmm. Pardon my thickness, but what exactly do you mean by "hardware
scrolling" here? Blitting the screen down a line? Copper manipulation?
If you're talking about blitting, then it might become expensive with several
bitplanes and very high frame update and scrolling rates.

Copper manipulation would be tricky. This doesn't stop me, though (it never
does ;-) from pondering funky ways of solving the problem by using massive
copper list manipulation instead of massive blitting. I present one such
idea for your consideration.

Ideally, as you say, you want to draw the bits as few times as possible. If
it were possible, then it would be nice to allocate a bitmap slightly larger
than the screen, and simply construct the off-portion of the screen, then
scroll it on to the screen as needed by playing with the copper list.
Unfortunately, this would result in the memory area covered by the bitmap
"creeping" all over the place, and in the end it would be no better than
just allocating the whole danged bitmap in the first place.

So, what if we do this. First, divide the bitmap into horizontal slices, say
20 scan lines high for starters. Allocate two extra slices, one for offscreen
at the top, one for offscreen at the bottom. Unfortunately, the slices would
have to be the *full width* of the superbitmap. A bummer, but if the region
around which you want to scroll is more vertically oriented, then we're still
coming out ahead. Anyway, we create a copper list that successively loads in
the address of the each succeeding slice into the bitplane pointers, creating
a smooth contiguous display.

Question #1: Can the copper reload just the bitplane pointers
quickly enough to avoid blank scan lines between slices? If not,
then we're hosed.

Now, horizontal scrolling is achieved with "standard" copper list twiddling.
Vertical scrolling, on the other hand, is achieved by creating (via tiles,
or algorithms, or who knows what) the next slice to be scrolled onto the screen,
and integrating it into the copper lists. When a slice gets scrolled
completely off the edge of screen, it can be freed up and reused. It may
be desirable to leave some sort of "buffer zone" at the top and bottom if you
don't know which direction you'll be needing to scroll.

So, the end result is that you have created a circular queue of display slices
which allows the display memory to be run like a treadmill. The height of each
slice would determine how long you have to create the off-screen slice, but
also how much you have to create. Optimal size would depend on the
application.

I am convinced that if pulled off correctly, this could make for absolutely
lightning fast scrolling of an arbitrarily tall but finitely wide field, with
many bitplanes.

Question #2a: Is this feasible? I know I could do it on an Atari 800
using display lists, but my copper list experience is much
more limited. I can't believe that any of Jay Miner's older
machines could do something the newer ones couldn't...

Question #2b: If it is feasible, has it been done?

Question #2c: Is this what you were talking about all along Leo? ;-)

Well, that's all for today. Whew!

/.- -- .. --. .- .-. ..- . ... .- -- .. --. .- .-. ..- . ...\
/ Neil Weinstock | att!cord!nsw | "One man's garbage is another \
\ AT&T Bell Labs | | man's prune danish." - Harv Laser /
\.- -- .. --. .- .-. ..- . ... .- -- .. --. .- .-. ..- . .../

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!
\_ -_ Recumbent Bikes: UUCP: pacbell 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

This should probably be in comp.sys.amiga.tech, but here goes,
If you allocate and store all your bitmaps in ram, you are going to
be using a bunch of memory. There is no way around that. If you want
speed, storing in RAM is the best way to go. After that, check the RKM
for uses of Dual Play field and SuperBitMap. I think there are specific
commands for doing scrolling.

Don White
zehntel!donw
Box 271177 Concord, CA. 94527-1177

Follow-ups to comp.sys.amiga.tech please.

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.

Faery Tale is done this way. Faery Tale's virtual screen size is
HUGE.

­-_
Leo L. Schwab -- The Guy in The Cape INET: well!
\_ -_ Recumbent Bikes: UUCP: pacbell 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