e. If the software is running on a plain machine with no special equipment or video hardware, a software rendering engine should step onto the stage and do the job correctly, if more slowly.
A smart API like this is a big time-saver for developers and accelerator manufacturers. Thousands of games and dozens of video accelerator cards are on the market. The RAVE structure lets each accelerator card manufacturer write a single engine that will be accessible to each game designer through the RAVE interface. All engines will accept the same basic calls for rendering points, lines, and triangles, so all software will work with each board.
Actually, 3D RAVE is one of two Apple API sets for rendering 3-D objects. The other one, which is called QuickDraw 3D
, is a much-higher-level API that offers developers the ability to simply open up a window and hand QuickDraw 3D a file that describes a complex item. QuickDraw 3D will interpret the complex data structures and break them into such low-level items as triangles, lines, and points before handing them to 3D RAVE to do the right thing with the local hardware configuration.
Two Halves Are Better Than One
Apple split the APIs into two sets because its engineers realized that not all software developers are alike. Some developers wanted a powerful tool that would do all the rendering work for them. Those developers would use the full version of QuickDraw 3D.
However, others had invested a great deal of time and effort in their own rendering engines that provided a distinctive "look" for their games. Game designers may concentrate on different effects. One developer might include a complex rendering engine for dealing with effects such as smoke and fog; another developer might choose f
or the action to occur in clear light. Visual styles such as this are important.
Software companies with their own rendering engines still need an API such as RAVE. This allows them access to multiple machines with different accelerator cards. Their rendering engines break up the complex models into triangles and then RAVE handles the local details.
Although the RAVE API layer is meant to be a
low-level API
, it still offers a strong collection of the most important features. You can texture-map triangles with textures that are as detailed as 4000 by 4000 pixels. Z-buffering is available, but you can turn it off to save memory and add speed. Some game programmers have already calculated distance information in their code, and they're able to draw programs from back to front and present the correct information without help from a z-buffer. You can clip these operations to fit into windows and other shapes.
The API does not offer access to any higher-level features that
might be found in the full QuickDraw 3D API. That API offers commands that will open standard 3-D files and import them. Game developers must do this for themselves if they want to deal only with RAVE. Also, such higher-level constructs as smooth polygonal object models are missing. These constructs are a large part of the heavy overhead that graphics languages such as GL impose on the systems that run them. With RAVE, game developers don't have to worry about losing memory to these functions.
The Difference Engines
A general API (like RAVE) should offer the same effect on different platforms in a manner that is completely transparent to the software. For instance, the standard window accelerator will move rectangles around in the same way. A 3-D API must also offer consistency across platforms, but it would actually be better if it weren't perfect. This is because software developers don't want exactly the same thing to happen on each machine. They want the best possible image to eme
rge on each machine.
This flexibility is offered by RAVE's
Gestalt interface
and the different rastering engines. A game program might poll RAVE to find out which of the engines are available and also determine their performance.
If you install a high-speed hardware-accelerated engine, the game could load the most realistic, complex models and use them in the game play, knowing that the engine could deliver. If you have a low-speed software-only engine, the game would use lower-grade models to maintain performance.
The Gestalt interface also describes the different features available on the different accelerators. Some might offer texture-mapping, while others might offer higher-grade mapping with interpolation. Some might offer transparency blending, while others might use an alpha channel.
Some might handle depth through simple z-buffering, while others might add deep z-buffering or perspective correction. Through the Gestalt interface, the game can poll the
local hardware and choose the appropriate object models to fit the performance characteristics of the board.
When the software begins executing, it can flip through a list of the available low-level RAVE engines and choose the best one for the job. It is quite possible that a package might forgo a zippy hardware accelerator engine for a slower software-only engine because the software-only engine offers features that are not available on the accelerator engine. If the software-only engine still renders the image fast enough, it would be the right choice for that situation.
This information is available through the Gestalt interface. Giving the software developer access to these choices is an important item if they're going to be able to tailor the drawing to present the best possible image on each machine.
This Gestalt interface also offers a surprising amount of forward-looking cross-platform flexibility. It is entirely possible that software written to the RAVE standard will run in seve
ral years on hardware accelerators that weren't even designed when the software was written. The software will access the Gestalt interface and choose the best-performing engine that's available.
Cross-Platform Wintel and Mac
The original core of RAVE was designed as a hardware abstraction layer (HAL) that would hide the details of each accelerator card from the Mac programmer. Once the abstraction is set up, it is not much trouble to extend this to work well on Windows machines as well.
As of this writing, Apple has said it will ship a version of RAVE for Windows programmers. This will let game programmers write to a single low-level standard and have their software run on either machine. In essence, the game programmer makes the same call to draw a texture-mapped triangle on either a Mac with a Matrox card or a PC with an ATI Technologies accelerator card.
The Windows development kit contains a Software Development Kit (SDK) with DLLs for the game programmer and a devi
ce-driver kit (DDK) for the board manufacturer. Both kits contain the definitions for the data structures that work consistently across both platforms--they are just recompiled for use on the PC. The Mac kit's SDK for the game programmers includes the headers for the system calls that are part of the QuickDraw 3D system extension. The board manufacturers can develop their own system extensions.
Apple has been the source of a wide variety of cross-platform standards, but its most successful ones have come in the graphics arts world. QuickTime and its virtual-reality cousin QuickTime VR are used on a number of CD-ROM games and graphics additions. The domination of the Mac platform in the graphics arts world helps this process.
If RAVE succeeds in helping 3-D game developers market their products, Mac users will benefit. Porting PC games to the Mac will be a relatively simple process, and there will be more games. The work may also flow in the other direction. Porting games from the Mac to the PC w
ill be an easier process. That will allow graphic designers who cling to the Mac to stick with it into the future.
Info On the World Wide Web
http://www.info.apple.com/qd3d/qd3d.html
(Netscape frames)
Crave the RAVE
