bosch@dg.dg.com (Derek Bosch) (02/27/89)
Hi! I am working on a couple of projects that require extremely fast 2-D scrolling of a 16 or 32 color playfield. The entire display is going to be roughly 4 lo-res screens high, by 5 lo-res screens wide, so that would be too large to have a SuperBitmap to scroll around (and still have any free memory left :^P. What other options do I have? These projects require as fast screen updates as possible. Any suggestions will be greatly appreciated! Derek Bosch Data General
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/02/89)
In article <112@dg.dg.com> bosch@dg.UUCP (Derek Bosch) writes: >The entire display is going to >be roughly 4 lo-res screens high, by 5 lo-res screens wide, so that would >be too large to have a SuperBitmap to scroll around (and still have any free >memory left :^P. What other options do I have? [ ... ] 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!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac 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
donw@zehntel.zehntel.com (Don White) (03/03/89)
In article <112@dg.dg.com> bosch@dg.UUCP (Derek Bosch) writes: >Hi! I am working on a couple of projects that require extremely fast >2-D scrolling of a 16 or 32 color playfield. The entire display is going to >be roughly 4 lo-res screens high, by 5 lo-res screens wide, so that would > Derek Bosch > Data General 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.
cg@myrias.UUCP (Chris Gray) (03/04/89)
In article <10871@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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. 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
bosch@dg.dg.com (Derek Bosch) (03/07/89)
In article <10871@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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. 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. It seems that at first glance that 1) would be faster, but I don't know. Anyone out there know for sure? 'tanks a lot! -db-
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/09/89)
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. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac 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
nsw@cord.UUCP (Neil Weinstock) (03/14/89)
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 / \.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . .../
jesup@cbmvax.UUCP (Randell Jesup) (03/15/89)
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. I dunno. Try it. It may depend on bitplanes/resolution. >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. Sounds neat. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
w-colinp@microsoft.UUCP (Colin Plumb) (03/18/89)
I'm pretty sure this is feasable. Handling multiple bitplanes is tricky (you have to change them all in one scan line), but I think it can be done with some ingenuity... Don't bother with the slices. Each bitplane is as tall as the screen, plus some slop for off-screen rendering. Initially, you start the display at row 0 and it goes to row n-1. Rows n through m-1 are off-screen. Then, as you scroll down, rows 0, 1, 2, 3... fall off the top, and rows n, n+1, n+2, n+3... appear on the bottom. When row m would be needed, stick a copper instruction into the display list to reset the memory pointer to row 0. Then this instruction moves up the copper list until it gets to the top of the screen and we're back where we started. For multiple bitplanes, stagger them so the copper instructions are between different scan lines. Thus, only two registers (BPLxPTH and BPLxPTL, the high and low halves of the pointer) have to be reset in one scan line. Seems doable. To render into this bitplane, you can write your own graphics routines that understand the need to wrap around, or do nasty things to the layers.library and let it worry about the discontinuity in the circular buffer. You can also use this to scroll horizontally, although you have to be more careful - I doubt you can jump from end to beginning of your circular buffer in mid-scan-line. Maybe someone more into graphics hacking than I (Leo? Have you finished Onion yet?) can write some sample code. -- -Colin (uunet!microsoft!w-colinp) "Don't listen to me. I never do." - The Doctor