Background Information
Before we can start optimizing, we give you an overview of issues that
are causing these speed problems.
CD-ROM
When your title is running from a hard disk loading isn't a big problem,
but on a CD it is. Yes, even on those blazing fast 6x speed CD-ROM players.
Why? You can compare the mechanism of a CD-ROM with a VCR or tape-stream;
when it reads media from the tape it goes fast, but as soon as it has to
move to another position (like 30 minutes into the tape), it will take
a while. A tapestream moving to another position (we will call it seeking
from now on) takes possibly a few seconds; a CD-ROM player takes far less
time, about a quarter of second. This may not seem very much but when you
know that for opening a file the MacOS needs sometimes 2 seeks you will
lose already half a second before reading any data. In AMT all your media
is saved as separate files. If you have 30 media items on one screen your
title will spend 15 seconds just moving around your CD-ROM. Optimizing
your title for CD-ROM is mainly avoiding seeks. There is a third party
product on the market that solves this problem. If you are targeting your
title for the mass market, 2x CD-ROM players are most common. Those CD
devices only read 300 Kbytes per second, so we have to avoid reading unnecessary
data from the CD-ROM.
Operating System
This may come as a surprise to you, but the Operating System itself
is also a bottleneck. AMT stores all its media as separate files. When
your title has to load a media item, it first has to locate the file on
your CD, then open the file, and finally read the data into memory. AMT,
like any application, does this by using standard Operating System calls.
On the MacOS these Operating System calls are not optimized for CD-ROM;
as we mentioned before, it does sometimes take many seeks. If you run the
same title on the Windows platform you will notice that the title loads
faster. [We don't take into account drawing speed]. You will see later
that there is a solution to this problem.
The MacOS, however, has very good multimedia software built in. Think of
the Sound Manager, which allows us to play sounds, QuickTime, for playing
back video, and QuickDraw, a highly optimized set of routines to draw pictures
to the screen. On the Windows platform this is now slowly being realized
as well, and we start to get the same performance we have on the MacOS.
Video Hardware
In the early days of multimedia slow video hardware was a big problem,
especially on the Windows platform, but nowadays we all have very fast
video hardware. Video hardware determines how fast your screen can be updated.
Most of the time we speak of frames per second. If you are going to create
a title that uses sprites or animations, the drawing speed is very important.
We will explain how you can influence the drawing speed.
Apple Media Tool
AMT divides your multimedia title up into different screens. On every
screen you have a list of media that will be used. When an AMT title goes
to a screen it first has to load all the media into RAM or, in the case
of a QuickTime movie, open the first data segments of the movie. In this
article, we will concentrate mainly on reducing the load time between two
different screens.
Some of the first time multimedia developers easily create titles that
use a lot of memory; we have seen many titles that needed 20 MB of RAM
to run. We will explain how you can reduce the memory requirements of your
AMT title.
How AMT draws it media to the screen
To do flicker free drawing to the screen, AMT draws first all the media
in an invisible window (or offscreen) and then copies the complete result
to the screen. Why offscreen? In the example below, the screen is composed
of 2 images: InfoPart and MenuPart. Menupart is stored in a very fast format
and draws immediately to the screen. Infopart is stored in a compressed
format and takes a while to draw, for example 1/2 second. If AMT were to
draw the media directly to the screen we would first see Menupart and then,
about 1/2 second later, InfoPart. This doesn't look nice, and that is why
AMT composes all of the media into an offscreen window first, and then
draws (also known as "blits") the complete result to the screen.
This last step goes very fast. Most of todays multimedia PCs are capable
of doing this at 60 times per second when the monitor is set to 256 colors.
figure 1: Drawing process
Remark: some media draw directly to the monitor, for example
QuickTime movies and QuickTime VR movies. Only in very special occasions
do these media not go directly to the screen, but for info on that, look
into the movies chapter.
The order of drawing these media offscreen is determined by the order they
appear in the Object list.
figure 2: Drawing order.
In figure 2, the first element drawn offscreen is the background image
"S2_MSRN.PIC", followed by the other media in the list.
Remark: When a certain area of the screen needs an update all the
media that intersect with this area will be redrawn. An example: when you
click on a button, a button image will be shown. Now not only the image
is drawn to the screen but also the part of the background image that intersects
with the button. In which cases can this be important? Assume your background
image is compressed and takes 2 seconds to draw. When you click on the
button it will take 2 seconds before you will see the button image appear.
There is a solution, but for that look at tip picture[1] in the optimizing
pictures section.