kasper@csli.STANFORD.EDU (Kasper Osterbye) (04/05/88)
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. I make an off-screen rasterport to draw into, so that I should not have to scroll the rasterport on the screen (I use a HIRES 16 color screen - to big?) My scroll loop looks like this Scroll of screen rasterport 1 to the left Using the build in rasterscroll. Draw one vertical line of new background. Copy the off-screen raster to the Screen raster Using the BltBitMapRasterPort procedure. This came out hopelessly slow, so what do I do? - Take a low res low color screen - use BltBitMap directly (is there a win there?) - Apply amiga-guro trick #71.4 for smooth scrolling backgrounds, only I do not know that trick -- Kasper
snyderw@pawl17.pawl.rpi.edu (Wilson P. Snyder II) (04/05/88)
In article <3313@csli.STANFORD.EDU> kasper@csli.UUCP (Kasper Osterbye) writes: >I wanted to write a little game. In that little game I wanted a background >to scroll smoothly to the left. ..... > I may be wrong, but I believe the fastest (and easiest??) method would be to draw the background into a wider-than-screen bit map and then change the pointers such that the 'view' moves along the bit map, in effect creating motion, but without memory moves. (MemView from the Fred Fish series is a up-down example of this.) Now, it should be possible to write the next line of data into the right edge, and then as the screen scrolls it would come into view. Assuming that you do not want to save the data, the memory could 'loop arround,' that is after X scrolls the starting address would be back at the beginning, in effect creating a circular queue. I used a method like this for scroling text on another system, so I have not tried this. ______________________________________________________________________ Wilson P. Snyder II beowulf!lunge!snyderw@steinmez.UUCP 318 Crockett Hall, RPI (uunet!steinmez!bewulf!lunge!snyderw) Troy, NY 12180-3590 518-276-2764, 802-658-3799 in summer ______________________________________________________________________
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/06/88)
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.
avery@puff.cs.wisc.edu (Aaron Avery) (04/06/88)
In article <3313@csli.STANFORD.EDU> kasper@csli.UUCP (Kasper Osterbye) writes: > Scroll of screen rasterport 1 to the left > Using the build in rasterscroll. Yes, ScrollRaster() is slow, since it has to move data in memory. >- Apply amiga-guru trick #71.4 for smooth scrolling backgrounds, only I OK, I'll tell you the best way I know of to do this and remain system- compatible. What you want to do is set up (and allocate) a BitMap which is the correct size for your entire background (if it's not too large). You then open your screen with CUSTOMBITMAP set, putting the BitMap into the NewScreen structure. Now, to actually do the scrolling, you find the screen's RasInfo structure, which is in its ViewPort structure, which can be found in its Screen structure. The value you want to manipulate is RasInfo->RxOffset. This controls the X offset into the bitmap at which the left edge of the screen begins. To update the display after changing the RxOffset, you might want to use ScrollVPort(), as it's the most system-compatible method, but I've found that it has flashing problems when there are many (more than 2) bitplanes present. You'll want to try it and see, tho. The other, faster, method is to call MakeVPort(), then MrgCop(), and then LoadView(). Hope this helps. Also, if your background is too large, you'll want to make a bitmap at least twice the width of the display, and do some judicious copying into it to effect a circular buffer. If you want more on this, please mail me. -- Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)