Memory Management Techniques

June 4, 2000
by Pat McClellan

Dear Multimedia Handyman,

I am building a CD-ROM and my minimum machine is a 350 MHz, 32MB RAM machine. Can you tell me what I should consider before diving in and making this CD?

Mike Oscar

Dear Mike,

I'm glad to see that you're planning for the lowest-performing machine in advance. Far too many projects get into trouble late into production because they have overlooked this concept. Test early and often on the lowest platform.

In most cases, the 350 MHz is not as challenging as the 32MB of RAM. Why? As a Director movie advances through the score, it looks ahead and preloads the graphics and sound that will be needed. That way, when it comes time to display it on screen, it appears smoothly. What happens when RAM is inadequate is that the program can't preload enough media to assure smooth playback. You'll see this exhibited as brief stuttering or pauses. There are a number of methods we can use to help monitor and control memory usage; we'll look at those in a moment. First, though, let's look at some general guidelines to observe when you know that RAM and machine performance are going to be challenged.

Make sure that all of your graphics are saved at the lowest acceptable bit-rate. Most users can't tell the difference between a 16-bit graphic and a 32-bit graphic that takes up twice the RAM. (Note: if you're using JPG compression on your Shockwave movie, you can keep your images at 32-bit. They compress to virtually the same size as 16- or 8-bit.)
Avoid any sequences where you are changing every (or nearly every) pixel of every frame -- basically, full screen animation is out of the question. You can often simulate full screen animation by using a static background image, with smaller animations running at various points on the screen.
Plan for a frame rate of about 10 or 15 frames per second. If you find you need more than that, then you're really going to have to test it on the lowest platform and see what you can get away with. A slower frame rate gives the computer time to load the next bit of media into the memory before it is needed, avoiding pauses in your animation.
Avoid really long audio clips. Better to cut them up into smaller pieces that can be individually (and quickly) loaded into memory prior to use. That could be a problem if you have music in the background. For background music, I recommend creating a small loop of sound -- maybe 15-20 seconds -- that will play in a separate track from any voice over. I suggest keeping all of your audio at the same bit-depth and sample rate, especially if they're going to be mixed and played back on Windows. And like the graphics, make them as small as quality allows by reducing the sample rate and bit-depth. If this program is played back over typical computer speakers, you don't need CD-quality sound.
Don't expect high-end digital video playback. There are some fantastic codecs (Sorensen for example) out there that really cram a lot of video quality into small files. But remember that the files are only small before they are decompressed by the codec. This decompression requires a lot of processor power and fills up the RAM quickly.
Don't expect elaborate animation or compositing of Flash members. This too requires a lot of processor power.

Overall, think about creating a program that provides for smooth and steady flow of small pieces of data. Structure the program so that there are natural pauses where the program is looping (and preloading media to come) before media-intensive sections of the program.

Director does a pretty respectable job of memory management in most cases. Of course, to do its job automatically, Director makes some pretty broad assumptions that you may want to override through the use of Lingo or other means. For starters, as the projector moves through the score, it can only assume that you're going to move through the score in a linear fashion. It also assumes that you're not going to be going backwards. Further, it assumes that all cast members are of equal importance. Based on these assumptions, Director constantly looks ahead to the frames immediately to come and preloads the members, making room for the new members in RAM by purging media that has already been used.

The problem is that you don't always move through the score in a steady forward motion. So Director's default processes could be purging media from RAM that you need, in order to make room for media that is not of immediate significance. But you can control that by changing the default setting on the Unload priority of a member.

Take a look at the explanation of purgePriority in the Lingo dictionary or in Director's Help utility. No need for me to explain the functionality further, except to give some pointers. I have never, ever needed to set the purgePriority of any member to "0 - Never". In fact, this is a bit dangerous, as you can end up filling up the available RAM with no way to purge it. However, it's not a bad idea to set the purgePriority of certain members to 1. For example, you might want to set all of the UI elements and sound effects to "1 - Last" so that they are immediately available.

Now let's look at some tasty morsels of Lingo that are indispensable to memory management. Let's say that you have a logo animation that goes from frame 31 to 60. How much RAM will that require? How do you know? It would be great if there were some function that told us how much RAM is needed...something like ramNeeded (firstFrame, lastFrame).

Yep. In authoring, you can just check it by typing this in the message window:

put ramNeeded(31,60)
-- 8703180

OK, so what does this mean? The result is 8,703,180 bytes, but we hardly ever think in terms of bytes. To convert this to something more meaningful, divide the result by 1024 to get kilobytes, and again divide by 1024 to get megabytes.

put ramNeeded(31,60) / 1024 / 1024.0000
-- 8.2998

So we can see that this sequence will require 8.3MB of RAM. If we happen to be looping in frame 30 waiting for the sequence to be triggered, there's a good likelihood that all of the media will be loaded up into RAM automatically. But what if our score is not linear? What if we're looping in frame 173 instead? If we rely on Director's automatic memory processes, it will be focused on preloading the media for frames 174 and beyond. So we might want to put a script in frame 173 that preloads frames 31 through 60. Actually, if we're looping in 173, we wouldn't want to repeatedly issue the preload command, so let's put the command in frame 172. That way it only gets called once and it can continue its work as the play head loops in frame 173 (remember that preloading takes some time.)

preload (31,60)

Take a look at the preload() command in the Lingo dictionary for more details and options in specifying the frames.

Now, let's say that we've played through the logo animation sequence and we know we're not going to be playing it again soon. If you're the fastidious sort who likes to clean up after the party before going to bed, you might decide to purge that animation sequence from the RAM to make room. Note that it's not really necessary, because other incoming media will force it to be purged, but just in case...

unload (31,60)

There are some other very helpful commands with which you should familiarize yourself. Among them: preloadMember, freeBytes, freeBlock, and memorySize.

Memory management is a bit difficult to teach as an absolute science because each program has its unique media requirements, structure and program flow. It's really more of an art that is perfected through experience and an inordinate amount of testing and adjusting. Good luck, and keep reciting the mantra: test early and often on the lowest platform.

Patrick McClellan is Director Online's co-founder. Pat is Vice President, Managing Director for Jack Morton Worldwide, a global experiential marketing company. He is responsible for the San Francisco office, which helps major technology clients to develop marketing communications programs to reach enterprise and consumer audiences.