Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!stpeter.Eng.Sun.COM!cmcmanis From: cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga.tech Subject: Re: Scrolling in 512K - Advice? Keywords: amiga 512k scrolling bitmap graphics Message-ID: <2259@exodus.Eng.Sun.COM> Date: 7 Nov 90 00:34:11 GMT References: <1149@xroads.UUCP> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 70 In article <1149@xroads.UUCP> aman@xroads.UUCP (Chris Minshall) writes: >I need some advice on how to create a scrolling screen for a program that >will run in 512k. I need to create a display that is roughly a 1280x1280 >bitmap to scroll around in (the actual display will show 320x200 at a time). >Such a large bitmap cannot be created at all on a 512k machine and just >barely on a 1 meg. Does anyone know of a technique that would allow one to >create a scrolling display using a small bitmap (emulating a larger one)??? >Any help would be appreciated. There are a couple of ways you can do this. They revolve around using the disk drive as a "backing store" for the image data. If your bitmap is unique for each pixel, then you can store (n X m) sections of the bitmap in a compressed format on the disk. Careful layout of the disk can insure a minimum of seeking. If you use the ROM based disk drivers (ie Read() and Seek()) then you can also use the ram disk if it is available on systems with more than .5K) You keep in memory the "view" bitmap and bitmaps for the four edges of that bitmap. This allows you to scroll on one of the edges when they are needed. When the edge bitmap is scrolled on, you can then start another task to begin loading a new "edge" into the area vacated by this scrolled on portion. (ASCII image follows :) +---------------+----------------+ | Left Upper | Right Upper | | Panel | Panel | +---------------+----------------+ +---------------+ +--------------------------------+ +----------------+ | Left Panel | | | | Right Panel | | | | | | | +---------------+ | | +----------------+ | Left Panel | | | | Right Panel | | | | Viewing | | | +---------------+ | | +----------------+ | Left Panel | | Area | | Right Panel | | | | | | | +---------------+ | 320 X 200 | +----------------+ | Left Panel | | | | Right Panel | | | | | | | +---------------+ +--------------------------------+ +----------------+ +---------------+----------------+ | Left Lower | Right Lower | | Panel | Panel | +---------------+----------------+ The panels in this ficticious example are 160 X 50 bitmaps that are compressed on disk. The entire bitmap is then broken up into panels and you need only make sure enough panels are in memory to scroll smoothly onto the next panel. The size of the panels will be determined by how fast you scroll across them. Because in this example the panels are 1/8 the size of the bitmap, you will need 2.5 bitmaps worth of space to store them in memory or 5000 bytes/panel or 20 * 5000 = 100,000 bytes. Roughly 1/4th of the available 400K on a 512K machine. The other alternative is the "pattern space" bitmap where the bitmap is actually a bunch of (n X m) squares that each contain 1 or 2 patterns. This allows you to store the patterns in memory an then just keep an array of patterns to represent your bitmap. This is what some of the adventure construction sets do. If you are really clever, you can make your set of patterns a color font and use the intuitext functions to build your bitmap. Then your bitmap becomes a series of lines of text that you can use the system blit routines to layout for you. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"