🚀 go-pugleaf

In article <3313@csli.STANFORD.EDU> kasper@csli.UUCP (Kasper Osterbye) writes:
>Hi,
>
>I wanted to write a little game. In that little game I wanted a background
>to scroll smoothly to the left. It prooved to be more difficult than I
>hoped for. Here is what I did, but it is utterly slow.
	[Edited of 'what he did']

A couple of things, one when you display 16 color high res screens you
eat a lot of the chipmemory bandwidth. That means that the blitter and
68000 have to fight to get in there and change those bits. This will be
slow. I wrote a Life program (coming soon to a BBS near you) that runs
at 6 gen/sec in 'low-res' 3 bitplanes, an 2 gen/sec in 'hi-res' 3 bitplanes.
(Although I wasn't trying to make it go fast, but given the exact same code
you can see the slowdown is about 66%) You can either use fewer colors
or fewer pixels. Both techniques will speed up your scrolling. 

Second, it is easier to (for me at least) to build is superbitmap window
and use 
	RX.Offset++;
	SyncSBitMap();

To scroll. You have to check for the case where you get to the end of 
your bitmap and then zip back to the beginning. One way to do this is
to have the superbitmap exactly twice as wide as your window/screen.
When you get to the end you render the new screen into the other half
and jump to that side. This can be expensive in memory though, 1280 X 400
(or 800 X 400 as I used) takes up 256,000 bytes of CHIP ram (160,000 in
the 800,400 case). So there are a couple of options. You could also
use your current technique with a superbitmap window that is only slightly
bigger than the window displayed. Note however that bitmaps come in 
multiples of 16 pixels wide, even when you want them to be smaller so
take advantage of those extra pixels and make them the 'shadow' area
for the stuff scrolling on.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.