Xref: utzoo comp.sys.amiga.tech:4137 comp.sys.amiga:30623 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!tank!ncar!unmvax!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!att!cord!nsw From: nsw@cord.UUCP (Neil Weinstock) Newsgroups: comp.sys.amiga.tech,comp.sys.amiga Subject: Re: Fast 2-D Scrolling Method Needed (kinda long) Summary: old subject, back from the dead Keywords: vague ideas Message-ID: <736@cord.UUCP> Date: 14 Mar 89 05:15:23 GMT References: <112@dg.dg.com> <10871@well.UUCP> <113@dg.dg.com> <10921@well.UUCP> Reply-To: nsw@cord.UUCP (Neil Weinstock) Distribution: na Organization: The Flying Squid Patrol Lines: 80 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 / \.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . .../