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.
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.
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.
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.)
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.
Now, how about a machine for your development software? My poor 486, the victim of much past experimentation, was my NT guinea pig. Setup of NT went relatively smoothly, and after resolving a couple of driver problems with my network adapter, I was up and running. With only 16MB of RAM, however, the performance was slow. This was especially noticeable when I tried manipulating large images in Photoshop.
Both my 486 and the HP Vectra were Intel-based computers. Although NT operates on four platforms, the selection of non-Intel applications will probably disappoint you. Only a few products, including Avid's Elastic Reality, are heavily pursuing the non-Intel markets. Most software vendors consider compliance with Windows 95 a high priority, so many of the applications they develop run on Intel-based Windows NT.
Keep an eye on the Alpha platforms. In light of Digital's recent alliance with Microsoft, the Alpha chip could soon become a major player in NT multimedia, especially for high-end graphics and 3D applications. For example, Autodesk's 3D Studio MAX, is written only for Windows NT and currently supports only Intel and Alpha.
For the most part, existing video cards, audio cards, and other multimedia hardware should function under NT. Once again, NT does not support DOS or Win16 device drivers, so make sure you get a Windows NT driver for any card or other device that you want to use. Microsoft has a "Windows NT Hardware Compatibility List" that will help you determine if drivers are available for your specific device.
The Future of NT Multimedia
A recent Microsoft article that compared NT and Windows 95 states: "You can plan for the future by making all new hardware purchases compatible with Windows NT." It appears that Windows 95 is part of a plan to migrate Windows 3.x users toward a future version on NT and that NT lies in the future of Windows multimedia. In fact, certain elements of Windows 95 can offer NT users a glimpse into the future of multimedia on NT. In particular, look for new multimedia APIs, the introduction of the RenderMorphics Reality Lab 3D graphics engine, and software-based MPEG video. According to Microsoft, the company will include all these advancements in a future release of NT.
The multimedia APIs that ship with Windows 95 generally show an integrated approach to multimedia and allow software and hardware to work together easily. Known collectively as the Windows 95 Game SDK, the Direct Draw,DirectSound,DirectInput, and DirectPlay APIs allow developers to directly control multimedia devices and obtain high performance from multimedia elements without having to delve into device-specific programming. Although these APIs were designed primarily for game developers, they will benefit other multimedia development that demands high media performance.
Microsoft developers also plan to put 3D APIs in place for Windows NT. A version of OpenGL already exists on NT: It's designed for high-end 3D applications where accuracy is critical. As a complement to OpenGL, the Microsoft Reality Lab API is aimed at creating high-speed, real-time, interactive 3D graphics. It is an object-oriented, 3D rendering library that targets consumer-level or business multimedia titles where precise rendering is not too important. It's due to be released for Windows 95 during the first quarter of this year.
Anyone who has developed for the MPEG video codec knows that the MPEG "specification" is really more like a suggestion. MPEG video is processor-intensive and normally requires a hardware decoding board on the end-user computer. Although they are relatively inexpensive, these boards are often do not comply with the MPEG "standard." During May, 1995, Microsoft made plans with Mediamatics to include software-based MPEG decompression in a future version of Windows: This could reduce or even eliminate dependencies on decoding boards.
And the Verdict Is
For now, I'll be keeping my Macintosh for most of my media preparation and authoring: Macs still have more applications and multimedia hardware than does Windows NT. However, I'll probably establish my 486 as a Windows 95 test machine, and I'll push to get a Pentium NT machine for the majority of my Windows authoring. (All I want is dual processors with 256MB of RAM!)
I still have a way to go before I consider NT for the bulk of my development. Many of the major multimedia applications won't really take advantage of NT's capabilities--or even be available under NT--for at least the next six months. Even so, Windows NT will still play a key role in multimedia production by taking on the burden of digital video editing and 3D animation.
Windows NT is superior in most respects to Windows 95, and in almost all respects to Windows 3.x. It makes sense that NT is Microsoft's operating system of the future: It'll gain multimedia capabilities that will go beyond what Windows 95 will ever have. On top of that, I can get comparable workstation-like power under NT for a fraction of the cost of a Silicon Graphics machine. As for the Macintosh? Well, I admit I'll always be a little biased, but even I admit that NT seems poised to overtake Apple as the leader in multimedia technology--and many hardware and software vendors are just now taking advantage of this operating system's potential in the multimedia arena.
So, don't ask: "Can NT handle multimedia?" But instead ask: "Can multimedia handle NT?"
Macromedia * 800-326-2128
Macromedia * 800-326-2128
AimTech * 800-289-2884
Asymetrix * 800-448-6543
Adobe Systems * 800-833-6687
Fractal Design * 800-297-2665
3D Studio MAX
Autodesk * 800-964-6432
Avid Technology * 800-875-4699
Price: $795; $495 (Intel)
Adobe Systems * 800-833-6687
Avid Technology * 800-875-4699>
System Requirements: Truevision Targa 2000 video board
- "The State of Multimedia on NT" stated that Macromedia's Director comes with a DLL that directly accesses a video board. Director does not ship with such a DLL. The DLL referenced was from a third party vendor.