General Optimizing Techniques

Overview Introduction Background Pictures Sound Movies Text General

general [1]: Choose the right engine.


In Apple Media Tool 2.0:

Apple Media Tool is a very extensible authoring tool thanks to its use of engines. The AMT package is supplied with two engines: the Minimal engine and the Standard engine. The difference between these two engines is that the Standard engine allows you to include QuickTime VR movies in your projects. If you don't use QuickTime VR movies you should choose the Minimal engine because titles you build using it will require around 1.5 MB less memory to run. Recently, a number of third party engines have started to appear on the market. These add extra features to AMT. These features always use some extra memory, so be aware of this and check memory requirements.

Apple Media Tool 2.1:

There is only one engine as long as you don't use QTVR movies, it won't include the AML code for QTVR playback.


general [2]: Choose the right AML heap size


When you export your title as text, you will see that AMT generates a SOURCES folder. This folder contains a series of text files - one for each screen in your project, plus a couple of standard files called Hierarchy.k and Media.k. If you open any of these text files in a word processor you will see that they contain source code written in a computer language called Apple Media Language (AML). When you use Runtime Maker to build a standalone version of your title, it compiles these source code files into an optimized playback format - let's call it AML data. This data is stored inside the standalone application for the MacOS version, and in the PROGRAM.KWP file for the Windows version.

When an AMT title starts up, it divides its memory into three sections. The first section holds the media items for the screen currently being displayed. This section is called "external memory". The second section holds the compiled AML data. This section is called the AML Heap. The last section holds information the title uses to keep track of screens while it is running. This section is called the AML Stack.

You can set the size of the AML Heap and the AML Stack, and the rest of the memory allocated to your application is used as external memory. In general, you should not adjust the size of the AML Stack - which only takes up 64K anyway. It can be worth changing the size of your AML Heap, however.

The smaller the AML heap, the more external memory you have available to load media into. If you hold down the control key when you open your compiled title, you will see the following dialog:


figure 14: Set AML Heap Size

You can now set the size of the AML Heap and AML Stack for the application. If you rebuild the application using Runtime Maker, these values get reset to their default settings.

Warning: if you set the AML Heap memory too low your title won't work. If this happens your title will either fail to load at all or, more dangerously, it may crash when you try to go to certain screens where AML needs more memory. Be sure to check all your screens after you have adjusted the AML Heap size.

Remark: when you press shift when you open your application, the free memory of those 2 heaps will be displayed in the upper left corner of your screen while the title is running. This can be useful if you want to see if you can reduce the AML Heap size.


general [3]: Split Up load


You may have noticed that transitions between screens can sometimes take a long time. This happens because AMT needs to load all the media for the new screen into memory before it begins the transition. This wait, which can be several seconds, can be frustrating for users.

To get around this, you can split your screens into two separate screens. The first screen (Screen A) contains half of the media items, and the second screen (Screen B) contains the full set of media. Now you first go to Screen A and after the screen is loaded go to the full screen B. Going from screen A to B can be done in "after display" or "before display" event part of one of the media. The total load and transition time of your title will not be enhanced, but the user will get a quicker visual feedback that something is happening.

You can enhance this technique even further:


Remarks:

Always verify that the media that is common between the two screens are included in the intermediate screen. If you don't, AMT will unload the common media and have to to reload them again. There is an important exception on this for QuickTime Movies or QVTR movies place them only on the final screen for AMT users or use the AMT PE. More info on this in the next speed tip.

By creating more screens, be aware that this will generate more AML objects, so your title will need more memory to run. The only solution to this is to do this in AMT PE (or with Runtime maker and editing your self the SOURCE files) where you can avoid using more objects. (except of the new screen object)

general [4]: Keep Common Media Items loaded but hidden


If you have a title that has a Main Menu screen which allows the user to access a number of further screens, where most of the time the user is switching between the menu screen and the other screens, then you should try to ensure that media items on the menu screen are not unloaded when you transition to one of the other screens. You can do this by placing items like buttons that are used on the main menu on the other screens as well - they can be hidden there if necessary. This avoids continually loading and unloading these media items.

Of course, if you have media items which are on several of the other screens, but not on the menu screen, you can also place these (hidden) on the menu screen.

Warning: using this technique means that the screens with extra hidden media items need more memory.

But it depends on which kind of media. I can tell you for sure about the following media:

1. Pictures.

2. WAV, AIFF,... sounds

3. Text

BUT!!!!! QuickTime movies are EVERY time reloaded, (I can't tell you for sure about QTVR movies, because the source code of this is hidden. But I think it is the same as for QuickTime movies).

Why (Technical stuff):

For every media that an AMT title uses there is a unique object that it's called a SUPPLIER. For every time the object is been used on a screen AMT creates a new object called a HANDLER. So if your object is been used on 2 screens there exist 1 SUPPLIER and 2 HANDLERS. The loading of media is normally handled in the SUPPLIER object and because both HANDLERs uses the same SUPPLIER object the loading never happens again when you go from Screen A to Screen B and the media is placed on both screen. Also when the same media is used more the once on a screen the media will be stored only once in memory.

But with Quicktime movies this is different because loading happens in the HANDLER's and will therefor happen always again for each screen because for each screen there is a unique HANDLER. Also if you use the same movie twice on the same screen it will be loaded twice.!!!

By knowing this every AMT PE can easily solve this, but AMT developers can also do this!

Solution:

1. On the "Screen A" where you use your QuickTime movie you add the following commands in the Before Display Event:

Show(itself)

[So this assures us that the movie always be visible when we come to this screen.]

Now when you go to "Screen B" you add the following command before the GoTo command:

Hide(<theQuickTimeMovie>)

[So this assures us that the QuickTime movie will be hidden when we leave this screen.]

2. Screen B, you do NOT place the movie on "Screen B" in the AMT tool!!!!

3. Do now Save As text... of your title

4. Open the SOURCES folder because we gonna adapt manually some code, don't worry it is easy.

5. Take the "Screen A" source file and open it in a simple text or any other word processor.

6. You will see something like this in the beginning of the file:

object oQuickTime_23 is cDefaultContainer
with
	Binder is oBinder;
	Label is -1;
	Items is [
		opaper_bg_only_23_1,
		opaper_bg_qt_23_24,
		oQuickTime_23_30,
		oexit_23_31
	];
end;

cDefaultContainer is the object that keeps a list of all the objects on screen. The list of objects (=HANDLERS) are stored in ITEMS. Now figure out which is your QuickTime movie. In our example this is <oQuickTime_23_30>.

7. Now copy this object name and place it in the list of "Screen B".

8. Compile now your title with Runtime Maker and you will see that there will be no disk access anymore!!!

Remarks:

* The best way to test this is to make Screen A and Screen B identically, except don't place on Screen B the QuickTime movie. There may be no disk access when you go from "Screen A" to "Screen B" and vice versa, except with certain QT movies, but this is complicated to explain and are really exceptions.

* In the case when you HAVE to use the same QT movie on "screen A" and "Screen B" then your in more trouble as AMT user because you have to code all the commands your self or choose not do so and have a slower title.

All this above could be avoided when AMT should support Background Screens (hopefully more then one)

general [5]: Slide Show with QuickTime


For those of you who need to create a slide show with, for example, 10 Pictures, don't load these pictures all at once as this will use a lot of memory. The best solution to this is by using Switch Media technique (see next tip). But it is also possible to do this with the following technique:

Remark: It is also a possibility to create a more flexible system with a hidden text track in your movie. Then with the AMT search feature you can locate the correct position in your movie and start playing your movie from there.

general [6]: Switch Media Technique


This is the most popular optimization technique and it is already frequently used by AMTPE developers. Thanks to the contribution of several dedicated AMTPE developers there is freeware code to do this available in the MediaSwitcher package on Mark Fleming's ftp site at: ftp://ftp.ccs.queensu.ca/pub/macintosh/amt2.0/

Now with the third party engine XMeDIA from The Carl Group AMT developers can also use this technique. It is also implemented in the freeware Art of Memory Engine, available on Mark Fleming's site. Also version 2.1 of Apple Media Tool will integrate switch media technique.

How does it work?

Imagine you have to create a small slide show with 10 pictures. All these images have to be loaded and you can display them in sequence using Hide and Show commands. Storing the 10 pictures at once takes a lot of memory and will slow down the loading of your title. With the Switch Media technique you load only one of these pictures and replace it by the next one if the user clicks the appropriate button. This way you only load a single media item at a time. This technique can also be used for movies, sounds and text.

Advantages:

Disadvantages:


general [7]: AMT Accelerator


Most of the techniques discussed so far reduce the amount of data that has to be loaded from the CD-ROM. But as explained in the "Background Information" section, CD-ROM is simply a slow medium to use. This problem is compounded by using a general-purpose operating system like MacOS or Windows. Data transfer rates from CD-ROM are very low, compared with hard discs, and operating systems are very slow at opening files and are inefficient at reading large numbers of small files.

For this reason, Director and other multimedia authoring tools use their own media database and bypass the operating system's file access bottleneck. Now you can do the same with AMT using AMT Accelerator from SKY4 STUDIOS.

AMT Accelerator stores most of your media items in a single media database file. This solves the problems caused when a general-purpose operating system tries to read media files from a CD-ROM, because the media items are stored in such way that CD-ROM doesn't have to move its reading head as much. This results in a significant speed boost for your titles.

For example, when your title has a screen with one big background image which takes 300Kbytes on disc and a dozen small buttons each taking up 30Kbytes, you will see a speed enhancement of 7 times. The example below shows the sort of speed benefits you can expect. As you will notice, much of the speed advantage depends on how many media items you have on your screen.


figure 15: AMT Accelerator advantage.

How It Works:

Before we start, you can download a demo version from the web-site of SKY4 STUDIOS at: http://www.sky4studios.be/.

This demo version works exactly the same as a normal version except that your title will quit after 7 minutes. Also the complete documentation is available online.

The AMT Accelerator tool works in two steps to accelerate your title:

1. In the first step it analyzes your project source code and adds extra AML code to handle access to the media database file. During this analyzing process the AMT Accelerator generates a list of media items used on each screen of your project.


figure 16: Source analyzing dialog.

2. In the second step it uses this media list to generate the actual media database. Here it is possible to add extra media items.


figure 17: Media List Window .

Advantages:

general [8]: Global Object


Before you start reading this tip, you should be aware of that in Chapter 3 of the AMTPE 2.0 User's Guide there is a more in depth explanation on this matter.

So what follows here is a brief explanation of this optimization technique, just to give you an idea.

Imagine that you have 100 screens and each screen has a quit button in the lower right hand corner of your screen, the same size and at the same location on every screen. On each screen you've programmed this button to do the same thing when the user clicks on it: Show a highlight, play a click sound, hide the hilite, and quit the application. The QUIT picture and the highlighted QUIT picture are the same for every screen.

You are rightfully proud of yourself for providing such a consistent user interface. Each Quit button has the same MouseUp Actions:

       SHOW Quit_Hilite
       START Quit_Sound

...and each Quit_Sound has the same Finished actions:

			HIDE Quit_Hilite
			EXIT (or whatever the action for "Quit The Application" is in
AMT)


But, AMT has no idea that you are being so consistent. So when you "save as text", for each screen, AMT generates a separate AML "object" for each QUIT button. In fact, it also generates a separate object for each highlighted QUIT button, and every QUIT sound.

If you look at the code that gets outputted when you "save as text", using a word-processor like Teach Text, you will see something like:

(on the first screen)

       object oQUIT_BUTTON_1_1 is cPictureHandler
       with
           ...
           has
             MouseDown(theTarget, theX, theY)
               do
                  oHILITE_BUTTON_1_2.Show(TRUE);
                  oCLICK_SOUND_1_3.Run(TRUE);
               end;
           ...
       end;

(on the second screen)

       object oQUIT_BUTTON_2_12 is cPictureHandler
       with
           ...
           has
             MouseDown(theTarget, theX, theY)
               do
                  oHILITE_BUTTON_2_13.Show(TRUE);
                  oCLICK_SOUND_2_14.Run(TRUE);
               end;
           ...
       end;

If you compare these two, you will notice they are identical except that "save as text" has cautiously added the prefix "_1_1" to all the things on the first screen and "_2_12" to all the things on the second screen...etc. It does this with all the best intentions, to make each object unique in case you decide later to move the QUIT button on screen 34 one pixel to the left without changing any of the others. AMT assumes every QUIT button may be different.

This would be no big deal except that in the case of your 100-screen application, AMT is generating 300 objects (a QUIT button, a QUIT hilite, and a QUIT sound for each screen) when you really only need 3 (one button, hilite, and sound, shared by all screens). The way this manifests itself is that your final AMT title starts to get progressively larger as you add similar screens. And your application starts to require more memory.

It's actually easy to fix...but you guessed it, you should really have a good tool like MPW to help you. Using MPW's search command, it is simple to find each occurrence of oQUIT_BUTTON<something> in all the <filename>.k files that "Save as Text" generates in the SOURCES folder for your application. If you type:

Search oQUIT_BUTTON .k

You will find there are two kinds of references:

1) oQUIT_BUTTON<something>,

and

2) Object oQUIT_BUTTON<something> is cPictureHandler

The first reference to oQUIT_BUTTON <something>, with a comma at the end, is usually inside the items list of the MEDIADISTRIBUTOR (screen). You need this reference to tell the screen to include the quit button. But you can (and should) get rid of the <something> suffix that AMK has prepended.

The second reference is the actual definition of the quit button object. You can get rid of ALL BUT ONE of these references and all their code up to and including the "end;" statement before the next "object ..." statement. The one remaining instance of oQUIT_BUTTON you should strip the suffix from so that it reads: Object oQUIT_BUTTON is cPictureHandler ...end;

Now, if you run the search for oQUIT_BUTTON <something> again in MPW, you should find a pile of

oQUIT_BUTTON,

references...

but only ONE reference to

Object oQUIT_BUTTON is cPictureHandler

You should try compiling with Runtime Maker (or MPW) again at this point to make sure you didn't miss anything.

If it's OK, you can go on to get rid of all the redundant occurrences (save one, which you renamed in a similar fashion, removing the suffix) of the quit button hilite and the quit button sound. Remember to change your sole remaining definition.

       object oQUIT_BUTTON is cPictureHandler -- got rid of the suffix
       with
           ...
           has
             MouseDown(theTarget, theX, theY)
               do
                 oHILITE_BUTTON_1_2.Show(TRUE);
                 oCLICK_SOUND_1_3.Run(TRUE);
               end;
           ...
       end;

to:

 
       object oQUIT_BUTTON is cPictureHandler -- still no suffix
       with
          ...
          has
            MouseDown(theTarget, theX, theY)
                do
                   oHILITE_BUTTON.Show(TRUE); -- no suffix;
                   oCLICK_SOUND.Run(TRUE); -- no suffix;
                end;
           ...
       end;

You've just saved yourself 297 objects (in our 100-screen example)which at let's say 200 bytes each saves you 60K of application size. And that was just (in your mind, anyway) one button! Obviously, you can apply the same technique to other redundant objects.

general [9]: Pre-Loading Media Items


When your title is going to transition to a screen that has a lot of media items on it, you can start preloading media items during idle time on the previous screen. This will reduce the load time when you transition to the second screen.

Be sure to also implement optimization general [11].


general [10]: Only load Media Items when they are needed


As has already been noted several times, AMT only shows a screen once all its media items have been loaded. However it is often the case that several of these media items are not used immediately - for example, you might build a game which plays a particular sound only if the user has correctly answered all the questions on the screen.

If your title contains a lot of these media you can use a technique called "Load when needed". If you are using the XMeDIA engine from the Carl Group, you can simulate this technique as follows:

AMTPE developers could produce the same code, but there is a more elegant solution available:

Remarks: Be sure to also implement optimization general [11] to get the best results.


general [11]: Asynchronous Loading


When AMT loads a media item into memory, it sends a message to the CD-ROM player to load the data and then waits until the data is loaded. This technique is called synchronous loading - the title can't continue processing until the load has completed.

This is a sensible policy for the AMT Framework classes to implement by default. But if you choose to implement techniques like general [9] and general [10], it can be useful to allow your title to continue processing while waiting for media items to load from CD-ROM, for example to continue playing an animation or to improve responsiveness to user interactions.

To do this, you need to alter the loading sequence so that media items load asynchronously. AMT already uses asynchronous loading when it plays ambient sounds - your title doesn't grind to a halt when the next block of an ambient sound is loaded.

Here is a possible implementation road map:

Remarks: This technique is only possible with media items like pictures, text, and sound. For QuickTime movies (including QTVR movies), the QuickTime extension is responsible for loading this data.

Warning: Never do asynchronous loading while you are playing back a movie or an Ambient sound, as two objects cannot access the CD-ROM simultaneously.


general [12]: Copy some data to the Hard Disk


You can improve the load times of media items by copying them to the user's hard disk. This technique is often used by catalog titles, which have relatively few media items. They will typically copy the application and the media items to the user's hard disc, leaving only the catalog database on the CD-ROM.

Generally, you will only want to copy a few frequently accessed media items to the user's hard disc. For general multimedia titles it is unusual to need more than about 10MB of hard disc space for your title. Fortunately, AMT is very good at handling this situation. The Switch Media technique allows you to alter the file name of the media item. It is also possible to alter the complete path of a media item. You can adapt the freeware MediaSwitcher code from Mark Fleming's FTP site. Then follow these instructions:

Other resources

http://macinfo.ccs.queensu.ca/Mark/AMT2/ Mark Fleming's web-site. It contains a lot of information about AMT. For example a link to his ftp site to download freeware AMT code and demos of commercial code, the latest version of the AMT/PE FAQ list, and a number of useful articles and pointers.
http://www.sky4studios.be/ On this web-site you can download a demo version of AMT Accelerator. This site also contains links to other AMT sites,...
http://www.carlgrp.com/ On this web-site you can find an evaluation version of XMeDIA, an excellent third party engine for AMT.