you can decompose this image into 3 little bitmap files + a correspondance table
Introduction:
The tile based scrolling technique has been used for ages by the video games industry, yet it's only been available to Director since its 8th version. It features lots of advantages, and applies particularly well to Shockwave, since it allows a minimal loading time.
This technique consists in decomposing a bitmap, on one hand in graphical micro-items, and on the other hand in a "map" of the graphic, as follows:
you can decompose this image into 3 little bitmap files + a correspondance table
Advantages:
Data Compacity
You can already see one advantage of this technique, which consists in "compressing" the bitmap by only storing its smaller common denominator, and eliminating redundancy. In this sample, the original bitmap takes 144x80 pixels, namely 11520 "squared pixels" to store, whereas with this technique you only store 3 images of 16x16 pixels, namely 768 squared pixels. Of course you'd have to substract the Run Length Encoding compression of Director to that amount, but still the benefit isn't less noticeable. One great advantage is that your bitmap can be huge while only taking a few kilobytes, as long as it only uses a few constitutive items. Moreover, by using vertical and horizontal flipping, rotations, ink effects, etc... you'll save a single graphic item to recreate very varied image pieces, while the loading time won't be increased.
The other interesting point is that the micro items (said "tiles") have to have a unique size for this technique to be applicable. In most games, the size of the tiles is 16 x 16 pixels, for video memory purposes. I can only recommend to stick to this standard, even though it's not necessary for it to work within Director, but just in case... you'll keep a format compatible with the games using this technique, and also with the different C sources, or with freeware graphics that you can find on the Web. In short, it's not essential, but it's not worth to go without it.
Scrolling
A second advantage of this technique concerns the image scrolling : imagine that the bitmap is way larger than the display area. You'll just have to recreate the bitmap in the size of the display area, and draw a "column" of additionnal tiles. Once the image has scrolled an amount of 16 pixels, you erase the first tile column of the bitmap, and you redraw another one at the other end of the bitmap, and so forth until you reach the end of the bitmap. Thus, you just redraw a very small part of the image at each update.
Example : this shockwave file containing the whole first level of Super Mario Bros only takes...
...8 Kb !!!!
Interactivity
The third advantage of this technique concerns essentially its application in the field of video games : as we have a cartography of a game level (the bitmap's map), we can use it to determine its interaction with a character : thus, if the character doesn't stand on a "brick" type tile, he falls, or, if he falls on a water type tile, he dies, etc... Of course this implies that each tile only has one and only one property. If you wish to have some non solid brick tile (for instance to create secret areas), you'll use a property list with varying properties.