Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!rutgers!att!cord!nsw
From: nsw@cord.UUCP (Neil Weinstock)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fast 2-D Scrolling Method Needed (kinda long)
Summary: Whaddya know
Keywords: scrolling ideas
Message-ID: <740@cord.UUCP>
Date: 16 Mar 89 19:51:37 GMT
References: <112@dg.dg.com> <10871@well.UUCP> <113@dg.dg.com> <10921@well.UUCP> <736@cord.UUCP> <6283@cbmvax.UUCP>
Reply-To: nsw@cord.UUCP (Neil Weinstock)
Organization: The Flying Squid Patrol
Lines: 83

In article <6283@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
>In article <736@cord.UUCP> nsw@cord.UUCP (Neil Weinstock) writes:
>>	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.
>
>It can.  The Amix console driver does this.  It only uses one bitplane
>at the moment, so to load several planes it might have to WAIT for a
>slightly earlier point.  Currently it waits for the beginning of the
>line.  (BTW, if it for some reason couldn't load them fast enough, the
>result would not be blank lines, but some extra continuation of the
>previous "slice"'s bitmap, and the current slice would be shifted to
>the right.)

Ahh, of course.  Given your scheme described below, it probably wouldn't even
be bothersome (maybe even not noticeable).

This Amix console driver only works if you're not running with windows or 
anything, right?  I can't even imagine a way to extend this to working with
windows....

[ ... ]
>>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.
>
>The Amix console driver does this with a few variations:  A "slice" is one
>scanline (i.e. it doesn't really use slices, it just starts the display
>at whatever line it feels like).  Since each slice (except the first one
>in memory) happens to immediately follow the previous one in memory, no
>copper action is necessary between slices except when the "last" slice
>wraps around into the first.  This means the copperlist really only needs
>one change to support this scrolling system:  At what would have been the
>end, it must WAIT for the spot where the memory bitmap will wrap around,
>and just MOVE the new BPLxPT values.  The current version does not have

I hope I would have thought of this if I actually had started to work on it
in detail.  So, if memory is a sheet of paper, you've simply rolled it into
a cylinder, and only need copper list stuff at the seam.  Neat.

[ ... ]
>>...  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.
>
>The height of a "slice" actually has no effect, it's the amount of "buffer
>zone" that determines how far you can stay ahead.  The "slice" essentially
>becomes an arbitrary, variable thing equal to however much you scroll in
>a given field.  For a video game you probably have to finish the update by
>the next frame, so it basically limits how many pixels you can scroll per
>frame without having some possibility of re-using some memory that is
>still being displayed.  If you're double buffering, you wouldn't need any
>buffer zone.

My feeling is that there are certain scenarios where you might want to build
a chunk of bitmap at a time, rather than scanline by scanline, even though you
are only scrolling one (or two or whatever) scanline at a time.  However,
given the fact that the notion of slices is really superfluous when using the
technique you described above, the amount of buffer zone becomes a simple 
thing to vary, without affecting anything else seriously.

>>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.
>
>It does.  Type "cat /etc/termcap" and you'll be dizzy real quick.

I'd love to get dizzy.  Care to send me a 2500UX? for evaluation? ;-) ;-) ;-)
Seriously, assuming that the text routines are quick, I can't imagine there
being a faster bitmapped scrolling screen anywhere (within limits).  Might 
make an impressive demo all by itself.

I must say it is refreshing to learn that some harebrained scheme I've come 
up with actually works and is being used somewhere.  I hope I get to write a 
scrolling game someday so I can try this all out...

 /.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...\
/ 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 /
 \.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . .../