Think of something that you wish Authorware could do but it doesn't? Let the our good friends at Macromedia know via the wishlist. Please let us know if you find any of the materials on this site inappropriate or offensive. Please include the url and why the material should be reviewed. Comments and questions about the site are also welcome. Please no Authorware questions, use the AWARE list. |
Back
11012 - Developing CDrom titles by - Jamil Zainasheff I've done quite a few CDs and have A LOT of advice on this subject. Of course
all of it is dependant on exactly what type of project you are trying to put
on CD. For example, if the program has sections of material that are likely
to be accessed in a linear fashion by the user, then make certain that all of
that material is in the same library. Often people divide their libraries by
sounds, graphics, text, etc. The problem with this is that the CD needs to jump
back and forth to read from these different libraries if, for example, it needs
to show a graphic and play a sound at the same time. What happens is that your
program runs r_e_a_l_l_y s_l_o_w. So, if it most likely that a user will see
certain material together, make sure it is in the same library. As far as a small apw file vs large, I always opt for the smaller file.
The whole purpose of the CD is so that you can have a lot of material available
without loading it on the user's hard drive. So, a small apw that pulls from
libraries on the CD is your best bet. O.K., I guess I opened my big mouth and now I have to deliver. Since a LARGE
number of people seem interested in how to go about optimizing CD-ROM/APW projects,
I decided to post this information to the list. As I have time (always in short
supply), I'll try and answer specific questions and give additional general
advice. First, let me warn you, each project is different. What your program does
affects how you set up the final project on CD. A program that uses lots of
video is quite a bit different that one that uses still images. The method I
use to get a handle on CD performance is to try and state how the program will
be accessed. For example: 1) The user sees the title screen From the statements in this example we can determine a few things about
our project. You need to decide what stuff requires quick access (copied to
hard drive during installation) and what stuff can be read off the CD. Items
that are displayed many times throughout the program need to be on the hard
drive. So, almost always, we want to put the shell of the program (that section
that contains the graphics for the navigation/interface items) on the hard drive.
In our example this would probably apply to the main menu and any common interface
items for the topics themselves. This will help them appear on the screen faster
(often this is all it take to make the user think the program is nice and fast).
Along the same lines, the first screen of major transitions (like jumping to
a new topic) should be on the hard drive if space permits. Again this makes
things seem faster when the user runs the program. If you choose carefully,
you can keep the size of the files copied to the hard drive relatively small.
Often I set up my projects with all the items that should be on the hard drive
in one library that can, at installation time, be copied/not copied to the users
hard drive depending on space/speed desires of the user. If you put 99% of your
content into libraries, your AP code will be fairly small and can always be
copied to the user's hard drive. I recommend always doing this (of course there
are specific exceptions which I'll have to cover in another posting.) You should set up your other libraries logically. For our example, you probably
would put all of your content (sound, graphics, text, etc.) for a topic in its
own library. This helps keep files that are accessed in a linear fashion next
to each other (important in CD access). And there is always linear stuff in
even the most interactive titles. I know you're saying "not in my title",
but even if that is not the case, often users will most likely pick a certain
path (see #3 above). If you can determine what that most likely path is, you
can do a better job of optimizing your CD. When you need to do something like #5 above (accessing graphics while audio
plays) you need to work carefully. While many CD drives have a buffer, don't
count on them for this type of access. If you have an audio track running from
the CD and try to display a graphic from the CD at the same time the audio will
stutter or stop completely until the graphic is displayed. A better method is
to decide which files can go to the hard drive and which should stay on the
CD. More often than not, you will put the smaller of the two on the hard drive.
BUT, you will probably see better performance from leaving the audio on the
CD if each individual graphic is small, or the reverse if each individual graphic
is very large. As far as video is concerned, it is best to leave it on the CD and compressed
for the data rate that matches your target platform (i.e., double speed). Remember
to only use 60% or less of the CD-ROM data rate. And, just like audio, don't
try to display additional graphics from the CD while playing a video. Now a couple of VERY general comments on CD file layout. When laying out
the file placement for your CD-ROM, the rule of thumb is to put your smallest
randomly accessed files closest to the center of the disk. Of course all the
rest of the files that are most likely to be accessed in a linear fashion should
be put right next to each other anywhere else on the CD. O.K., I've used much too much time on this. I'll try to put together some
more thoughts on this subject as I get time. Several people expressed interest
in the installation routines (what files where and why), and a few other topics.
I'll be glad to comment on your specific projects, BUT first please go through
the exercise of stating how your program is likely to be accessed by the user.
Once you've done that, include it with your questions. I know this took a bunch
of bandwidth, but I received a large number of responses on this subject. HTH. Jamil Zainasheff Add your review Back |