🚀 go-pugleaf

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: <none>   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!"