I remember going to an IBM presentation where the speaker ran a
Windows-based computer from the podium, but all the Windows computer did was
send signals to a Macintosh system that had been strategically hidden behind the
stage. Until recently, Apple Macintosh systems ruled the multimedia world.
Windows machines were considered great number-crunchers, but they just didn't
have the power to drive high-end graphics, audio, and video applications.
I wasn't surprised that the IBM speaker used a Macintosh system for a
behind-the-scenes workhorse because I've been developing multimedia products for
Windows (and even DOS) for a long time--long before multimedia and the Media
Control Interface (MCI) were standard PC fare. Unfortunately, multimedia
authoring under Windows has never been a particularly easy task: You run into "minor"
annoyances, such as system instability, conflicting device drivers, and slow
performance. Furthermore, many of the development tools I use are either
unstable or don't even exist under Windows. So, I have two systems on my desk: a
Power Macintosh 7500/ 100 and a 486 DX2. Both systems are loaded with the latest
multimedia hardware and software, but I usually develop large portions of
multimedia projects on my Macintosh and transfer them to the Windows machine
only if I need to.
The first time I saw Windows NT version 3.1, I decided it was just another
flavor of Microsoft Windows. I lumped it into that "I'll only use it when I
have to" category and promptly forgot about it. Earlier this year, though,
I was introduced to NT version 3.51, and I decided to reevaluate my opinions
about Windows multimedia development.
Multimedia Demands
When an NT user told me that NT can offer multimedia developers significant
speed and power advantages, I was intrigued. Multimedia production is a very
demanding application because it pushes your hardware, software, and operating
systems to their limits. To find out more about what NT had to offer, I borrowed
a Hewlett Packard Vectra XU 6/150 (a 150-MHz Pentium Pro with 32MB of RAM)
running Windows NT 3.51, loaded some of my favorite multimedia applications, and
began to play.
Time is the enemy in multimedia development, and nothing can consume it
more quickly than media preparation. Every developer can relate to the
frustration you feel as you watch a progress bar crawl across the screen at
deadline as you process an image, 3D animation, or video clip. In some cases, a
digital video or 3D rendering can take hours--or even days--to generate a few
minutes of final footage. These kinds of activities are very
processor-intensive and account for up to 70% of the total production schedule
(and budget). With the kind of speed you find under NT, the time you save over
the length of a project can be quite significant.
The familiar Windows interface greeted me when I started the HP and logged
onto the system. As a test, I started Adobe Photoshop 3.0.5, opened a full
screen, 16-bit graphic, and played with a few of the filters. I watched how fast
the progress bars moved, and using this highly non-scientific method, I
determined that NT is just plain fast! (See "Photoshop 3.0.5 for Windows NT"
on page 81 for more precise test results.)
Of course, the primary reason for this kind of speed is that NT is a true
32-bit operating system, which by itself is a great improvement over the 16-bit
Windows 3.x environment. NT also supports RISC technology, which gives
multimedia developers access to some of the fastest CPUs on the market today,
including the Alpha AXP, MIPS R4x00, and PowerPC chips. But perhaps even more
significant is NT's Symmetrical Multiprocessing (SMP). SMP allows one
application to take advantage of the computing power of multiple processors
simultaneously.
Stability
I wanted to see how well Windows NT works under stress, so my next
experiment was to run two of the 16-bit authoring systems that I use the most:
Macromedia's Director and Authorware. I'd heard a rumor that these applications
had problems running under NT; however, not once during my tests did NT hiccup
or break a sweat--even during some very complex animation sequences and
scripting tasks. I decided to break an NT cardinal rule and use a Dynamic Link
Library (DLL) included with Director that tries to directly access my Hercules
video board. Director came to a screeching halt, but Authorware and NT remained
intact and kept running properly.
Windows NT can offer this kind of resiliency because, unlike Windows 3.x,
NT runs all applications in separate memory-address areas (this includes not
only Win32-based applications, but Win16 applications as well). It completely
isolates the operating system from any application code. When an application
crashes, it is unlikely that either the system or another application will be
affected.
Under the NT architecture, applications can't directly access hardware, as
I confirmed with my Director DLL test. You must access all hardware, including
video drivers, CD-ROM drives, audio cards, and multimedia peripherals, through
NT drivers. At first, this might seem like a disadvantage to those developers
who are accustomed to bypassing the operating system for better performance and
hardware control. In actuality, NT's approach to managing hardware offers a more
stable environment without sacrificing performance.
Under the Hood
NT supports all the Windows 3.1 multimedia extensions and MCI commands. This
means you won't have to rewrite titles that use these extensions and commands.
(Do I hear a collective sigh of relief coming from multimedia developers
everywhere?) Even so, there are some significant improvements in NT that affect
how multimedia applications perform. The only way many developers will notice
them, though, will come from the enhanced performance of the media applications
and authoring systems they use every day.
For example, the quality of Video for Windows has been re-engineered for NT
3.51 so that it can support both 16- and 32-bit applications programming
interfaces (APIs). Nearly everyone is familiar with the usual signature of
software-based digital video: small size, blocky look, and inconsistent
playback. The major reason for these limitations has been the constraints
imposed by operating under a 16-bit architecture like Windows 3.x. Using 32-bit
APIs significantly improves video performance--You can see this when you use the
built-in Indeo and Cinepak coder/decoders (codecs).
3D animators will appreciate another significant advance: OpenGL. We've all
seen previews of what it can do--just look at the 3D screen savers included with
NT. OpenGL is based on original specifications by Silicon Graphics, and in
simplest terms, it allows for fast, very accurate, high-quality 3D modeling and
rendering. 3D applications access OpenGL at the software level and are isolated
by the presence or absence of OpenGL hardware acceleration. This means that
OpenGL allows the application to make the best use out of the hardware that is
available on your system.
Authoring Applications
Generally speaking, if you author on the same platform and operating system
that your end-users have, you'll significantly reduce the potential conflicts
and "quirks" you'll have when you finally test and deliver your
product. The bottom line is most end-users are still running Windows 3.x or
Windows 95, not Windows NT. Does this prevent developers from authoring on
Windows NT?
For the most part, authoring under NT for Windows 95 should present few
problems, unless you use direct commands for specific device drivers, such as
direct, non-MCI Moving Pictures Experts Group (MPEG) commands. When porting to
Windows 3.x from Windows NT, you may need to recompile your presentation with a
different runtime engine if you used a 32-bit authoring system. You shouldn't
have to recompile if you used a 16-bit authoring system. If you are converting
from NT to Macintosh, you'll need to compensate for system differences, such as
fonts and digital video standards (e.g., Video for Windows vs. QuickTime).
You should ask yourself which of your favorite multimedia development tools
can run in the NT environment. My own research revealed a mixed bag. (See "Media
Applications" on page 28 for the lowdown.)
Hardware
Because media elements typically contain huge amounts of data, you should
get as much of them into RAM as possible. This reduces frequent disk access,
which can totally negate the performance advantages of NT. Although the NT
Workstation specification recommends a minimum of 12MB, you should consider 32MB
of RAM as the absolute minimum.
Previous
