Cross platform fun

March 23, 1998
by Pat McClellan

Dear Multimedia Handyman,

I'm about to start my first cross-platform Director project. (I am comfortable with Windows, but I'm mainly a Mac kinda guy.) I want to be sure that I plan the project so that I don't end up with a bunch of cross platform problems. What should I worry about?

Mac

Dear Mac,

Director does a good job of behaving the same on Windows and on the Mac, to the extent allowed by the respective Operating Systems. Windows and Macs have some key differences that you should plan around, so it's good to see you're thinking ahead.

First, let me clarify that Director movies are "cross-platform", but Director Projectors are not. The actual executable file must be created on the respective platform, using that OS's version of Director. And yes, you do have to buy separate copy of Director. Let me stop you before you pursue the "cheap shortcut" that ALL of us have considered: No, I don't advise getting a friend to created a stub projector for you which simply goes to the dir file. If you're serious about cross-platform development, go ahead and get that second copy of Director. And abide by that mantra of every good developer... test early, test often, and test on the target platform -- both of them.

OK.... some things to consider: file names, file paths, linked media, digital video, sound differences, system palettes, font mapping. There are probably many others, but we'll start with these.

Filenames
On Windows 3.1, the file names need to conform to the "eight dot three" naming standard, such as "mymovie.dir". In this protocol, specific file names are eight characters or less, do not include spaces or non-alphanumeric characters, and are followed by a three character extension which tells Windows what type of file it is. For Director, the extensions are:

• *.dir for a Director movie
• *.dxr for a protected Director movie
• *.cst for a Director cast file
• *.cxt for a protected cast file
• *.dcr for a Shockwave compressed movie
• *.swa for a Shockwave audio file

Windows 95 and NT support longer file names and can "hide" the extensions. The Mac OS uses long file names, allows special characters and doesn't need extensions. So, now it's time for your first lesson in cross-platform compromise: conform to the least common denominator. That means that starting now, get in the habit of using file names that conform to 8.3. This will save you many hours of renaming frustration in the future. (I also recommend limiting your directory names to 8 characters, with no special characters.)

Pathnames
On a related topic, the file paths are different for Windows & Mac. A typical file path for your program running from CD-ROM on the Mac might be "Your CD:Movies:Your Projector". On Windows however, the name of the CD-ROM is not part of the movie path. Instead, it will be something like "F:\movies\program.exe", where F is the letter for the CD-ROM drive. The problem is that some other Windows system will play the same CD-ROM from the D drive. There's a technote that explains a method to dynamically determine the drive. You should also notice that the character used to separate each nested directory is different: colon on the Mac, slash on Windows. This will be important if you're specifying any pathnames. For more info on this, check out Macromedia's Technote 3125.

Linked media and digital video
Despite the differences in the file paths, you can use linked media with not too much trouble. Again, stick to 8.3 filenames. The key here is that since your media is not internal to Director, it must be in a format that is cross-platform. That means don't link to BMP files if you want it to run on a Mac, and don't link to PCT files if you want it to run on Windows. (For graphics, you'd need to use JPG.) Same thing with sound: WAV files for Windows, AIFF for Mac. If you have to have external sound files that are cross-platform, you could use Shockwave Audio (*.swa), or Quicktime movies that are sound only.

That brings us to digital video. The "standard" developed for Windows is AVI, while the Mac uses Quicktime. Luckily, there is Quicktime for Windows, making QT the cross-platform standard. However, it is vital that you save the Quicktime as "self-contained" and "Playable on non-Apple computers." These are options that are available in almost any program capable of saving QT movies. Of course, the video file should be named in 8.3, with the extension "*.mov".

Sound
Without getting into the technical details of how Windows handles sounds (where I would quickly find myself groping for understanding), let me explain it the way that I think of it. Windows sound sucks. More specifically, compared to the way that Macs handle sound, Windows REALLY sucks. So what's that mean for you as you develop in Director?

A few guidelines: use only 1 bit rate and sample rate for ALL sound in your program. I typically use 16-bit sound at 22.050 kHz. Note that 22.050 IS cross-platform, while 22.255 kHz will only play on the Mac. Use either 22.050 or 11.025 for good cross-platform dependability. And again, don't switch back and forth with your voice-over narration at 16-bit and 22.050 kHz, but your button sound effects at 8-bit and 11.025 kHz. Windows will screw it up.

A big problem with Windows sound is the inability to play internal sounds while Quicktime is playing. Apparently, when you play a Quicktime movie with sound, Windows "hands over" all of the sound processing capabilities to QT. And when QT is playing, Director has no access to playing other sounds such as button clicks, narration, etc. Also, if an internal sound is playing at the time when a QT movie begins, the movie will have no sound. So, if you have a button which activates a QT movie, and there is a sound effect attached to the button, it is likely that the sound effect will still be playing at the time the QT starts and you'll have no sound. You have to guard against this by putting in buffer frames and handlers which assure that no sound is playing BEFORE advancing to the QT movie. It really sucks.

For more details, check out Macromedia's technotes on the subject: Technote 3191 , Technote 3523.

System Palettes
It is important to include the first 10 and last 10 colors from the Windows System palette in whatever palettes you use for your program. Windows uses these colors (a few of them anyway) for things such as alert windows, etc. I know that you are compromising your graphics already by dithering them to 256 colors... you don't want to give up 20 more. Trust me, just do it. Create your custom palette of 236 colors instead, then merge in the first 10 and last 10 from the Windows system palette. The jump from 256 to 236 is hardly noticable and it will save you much time later.

Another palette consideration is the colordepth. While you can set the colordepth from Lingo on a Mac, most Windows machines require that to be done from a Windows control panel and then a system reboot. You can check to see what the colordepth is on Windows, you just can't reset it. Glenn Picher has written the DisplayRes Xtra which addresses this to the extent possible.

Fonts
There are really 2 issues here: fonts in field members and fonts in text members. As you know, fields use the playback system's fonts to generate the display. So, if you create a field on the Mac using Geneva, it won't look the same on Windows because Windows doesn't use Geneva. It will substitute something else -- but what? Well, the projector looks for a fontmap.txt file to tell it how to substitute. For a detailed explanation of this, search on font map in Director's Help utility. Keep in mind that even if you use a font map, your lingo scripts can get screwed up on things like "the lineheight". Test early and test often.

Now, fonts in text members are much easier to deal with. In text members, the font essentially gets bitmapped for display. This works very well cross-platform. Of course, you can simply open the text cast member for editing as text. But this convenience has a downside: if you open a text member for editing and the font in which it was created is not available, it will substitute something else. So if you create your program using Mac fonts, DON'T open your text members for editing on Windows or you'll screw them up. You'll have to go back to the Mac and edit them.

Summary
In some cases, you'll need to write "double-code"... one set of instructions to execute on Mac with other instructions for Windows. For example, let's say that you prefer the program to run at 8-bit. You can set this on the Mac, but not on Windows. So you might have a startMovie script like this:

on startMovie
        if the machineType <> 256 then
                set the colorDepth to 8
        end if  
end

I think that covers most of the big issues. I hope I haven't scared you away from cross-platform development. In fact, cross-platform capability is one of the primary reasons that Director has gained such a formidable market share. It has been my experience that those developers who take the time to master the cross-platform complexities are well-rewarded for the effort. Good luck with your project.

Copyright 1997-2024, Director Online. Article content copyright by respective authors.