🚀 go-pugleaf

In article <10921@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>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.

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 | nsw@cord.att.com | man's prune danish." - Harv Laser /
 \.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . .../