beeje@oocities.com

Back to Beeje's Home page

Graphics API Comparison

News:

• September 9, 1998: Two wooden spoons this month:

  Microsoft DirectX 6.0 SDK: Microsoft is now charging for the DirectX 6.0 distribution "to cover production costs." For a short time they did make it available at their web site, in a single convenient 90Mb file. Requests to provide it as several smaller files were duly ignored. How did this thing suddenly blow out to a whopping 90Mb anyway? The previous distributions were a fraction of this size. I'll go out on a limb and predict that now that MS have won over so many graphics vendors that now they're getting cocky, have decided they can get away with charging for the SDK, and don't really intend for anyone to get it off the web.

  Intel i740: The i740 is a nice graphics chipset, but one that has hardly taken the graphics world by storm. Why then are Intel making things harder for themselves (and especially their customers) by refusing to release the programming specs for this chipset to the Xfree 86 organisation? That's right; if you want to run X-windows with Intel's latest and greatest graphics chip you'll have to do it in 640x480 4-bit mode (yes; with count them: 16 colours!) So why won't Intel release the specs? They believe it'll compromise their trade secrets... for an also-ran graphics card.

• July 1, 1998: A year is a long time in the world of computer graphics! The OpenGL Direct3D debate ended up in a truce between Microsoft and SGI; they're both cooperating on a future API called Farenheit. In the meantime both OpenGL and Direct3D have persisted. OpenGL's survival owes a lot to John Carmack (DOOM) who articulated its advantages and proved them with QuakeGL. Direct3D's survival on the other hand owes a lot to Microsoft ;-).
• SGI renamed the CosmoGL "optimized OpenGL for Windows". This is a software renderer, so you'll only need this if you're not using a 3D graphics card. If you are using a 3D graphics card get one with an OpenGL driver for your OS. Not all cards have OpenGL drivers. Be sure to check for the availability of the driver before you buy the card.
• I did explore Direct3D RM in some detail. D3DRM will never give the superb effects you'll find in Quake or Unreal, but if you're pressed for time it will give you reasonable results for the time you invest in learning it. DirectX's API is general is unweildly. I've consistently found thought that you can hide its awfullness in a wrapper. More programmers should consider this approach; You can write a wrapper that with a few tunable defines can support any graphics API or target platform that you like.
• The big news is the increasing use of 3D graphics cards in consumer machines. Yes, they've been there for a while - but until now the results have been nothing to write home about, and people have been slow to upgrade their hardware. But the latest round of cards are impressive and cheap. I steered away from the VOODOO* chipset; I heard a rmour they only work in full-screen mode. For a software developer that makes for difficult debugging. I also steered away from GLINT who has a bad name for performance. But I did upgrade my PC recently and with it got an 8Mb i740 AGP graphics card. It's performance is phenomenal, but only comes with an OpenGL and DirectX 3.0 for NT, but can run DirectX 5.0 for Win95/98. Go figure? Intel/Diamond are promising an OpenGL driver for Win95/98 in the promotional literature, but I've yet to see it.
• February 28, 1997: CosmoGL is here. It's faster than the Microsoft's implementation, and comes with some fine demos. It's free, and you can download it from http://www.sgi.com/Products/cosmo/opengl/download.html.
• 15 February 1997: I'm making progress with D3DRM. It has some serious flaws (discussed below), but it works and the complex API can be hidden beneath a wrapper class. It took me two weeks to study the examples (picking through them line by line) and 3 days to code the wrapper class. Some of the example code provided by Microsoft turned out to have the sort of errors I used to mark down first year CS students for! Anyway, if you want to add 3D to an application quickly and can put up with the poor documentation then D3DRM is your man.
• 6 February 1997: Some general notes on my own exploration Direct3D Retained Mode: Problems include no support for LOD, and an apparent failure to distinguish models from instances of models. The vague documentation is a problem; the only way you can really understand the API is by "writing tests."
• No sign of CosmoGL, although it was due out this week (which started February 3). There appears to be more support from hardware vendors for OpenGL. 3dfx have written a "mini-OpenGL" driver to allow Quake to run on their Voodoo boards. It only implements part of the protocol, but 3dfx have said they will release a full version later this year.
• 30 January 1997: An electronic newsletter, "The Wave Report on Digital Media" http://www.fourthwave.com/wave contained a significant "exclusive" interview with Jay Torborg, Director of Graphics and Multimedia, Windows OS Division of Microsoft. Torborg admits ease of use, poor documentation and insufficient optimisation are indeed problems. Ty Graham of the Microsoft's PC Platform Team says Microsoft will skip a version and go straight to DirectX 5.0. He recognises that D3DIMs execute buffer mechanism is flawed. Instead Microsoft will release a new API called DirectTriangle. This appears to be a replacement for Direct3D Immediate Mode. They will also provide wrapper functions to hide some of DirectX's more tedious code. We're glad to hear Microsoft are finally acknowledging D3DIM's problems, but an announcement of this magnitude impacts anyone considering developing with Direct3D Immediate Mode. This announcement should have been released on the Microsoft web site. We should not have to hear about it second-hand!
• 21 January 1997: CosmoGL scheduled for release Week of February 3, 1997. Hardware vendor announcements expected soon.

Developers writing 3D applications for Microsoft Windows currently have three primary choices: Microsoft's Direct3D, SGI's OpenGL and Apple's QuickDraw3D. This document presents a brief comparison between them; notably Direct3D and OpenGL.

This document is continually being updated as new factors and experiences come to light. This is a rapidly changing area. In a months time it's recommendations could be completely different.

What's the difference?

All three graphics libraries discussed here generate images of comparable quality. They all use the same basic graphics techniques. Forced to draw the distinction I'd say the quality of OpenGL and QuickDraw3D's images is perhaps a little better than Direct3D. All three graphics libraries are "free" (either genuinely or hidden in the purchase price of the operating system).

The differerences are:

• Ease of programming.
• Marketing.
• Availability of drivers for Graphics Accelerator cards.

Marketing is a big concern. An API that is not accepted by the marketplace risks being withdrawn. The developer is then left with an application written for an unsupported graphics library. This even happens to the giants. Microsoft withdrew their WinG games library, and in late 1996 Intel withdrew support for their 3DR graphics library.

Software vs Hardware Rendering.

The graphics libraries discussed here all provide a software renderer which can work on any PC. Typically software renderers have a slow frame rate. Occasionally someone like Id Software will produce an especially good software renderer (for a specific type of 3D environment) that can generate fluid graphics even on mediocre PCs.

A 3d Graphics Accelerator card can speed up the rendering process by performing some or all of it in hardware. A particular card can only be used with a graphics library if the vendor writes drivers for it. Without drivers, the card is useless.

Any of the graphics libraries we discuss here could deliver stellar performance with the right graphics accelerator. However many PC owners still don't have these cards. A developer writing an application that can't run without a card will be restricting themselves to a smaller market. But the gaming industry relies on being able to sell a low-margin product (so far as the developer is concerned) at high-volume. For this reason graphics libraries still have to deliver acceptable performance without any hardware assistance. If a particular customer happens to have a graphics accelerator card, then all the better for them.

Direct3D 3.0.

Direct3D (aka D3D) is the 3D Graphics component of Microsoft's DirectX games development suite. DirectX is available free of charge from Microsoft. Direct3D is only available on Microsoft Windows 95. It only partially works on Windows NT.

Many hardware vendors producing Graphics Accelerator cards have announced they will be providing Direct3D drivers.

Direct3D can work in windowed or full screen mode. It supports an RGB "true colour" model, and a simplified (and faster) ramp mode. Ramp mode models light sources monochromatically. The scene still appears in colour. The only reason to use Ramp is for the improved speed.

Figure 1. Direct3D Retained Mode rendering of a Rat.

Direct3D provides two different APIs:

• Immediate Mode (aka IM or D3DIM).
• Retained Mode (aka RM or D3DRM).

Immediate Mode

IM uses a mechanism called "execute buffers." The application prepares all its graphics instructions by loading them into this buffer one by one. When it is ready the application asks IM to "execute the buffer." This is difficult to debug, since any error in constructing the buffer doesn't become apparent until you finally execute it.

IM is highly-system dependent. The execute buffer is an example of this; the maximum buffer size varies from system to system. What works on one PC may not work on another. IM represents the capabilities of graphics accelerator cards via "capability bits." The idea is that an application queries the hardware to see what it can and cannot do and tailors its behaviour accordingly. The trouble is the drivers aren't always reliable in reporting what they can do. In other cases the hardware may special rendering capabilities that can't be used because the capability bits to describe them do not exist.

Most troubling, capability bits mean your application will take different execution paths on different platforms. One developer who implemented a D3D game reported that the software renderer and six different hardware cards all worked differently, each presenting a new set of bugs.

No quantitative performance figures are available comparing D3DIM to the alternatives. The software renderer seems adequate.

Retained Mode

The major drawback with RM is that you're surrendering control to the D3DRM renderer. You lose the freedom to develop your own highly-optimised graphics algorithms, the way Id Software did with DOOM. Using RM may be easy, but for that ease you lose the freedom to make your application really stand out from the competition.

The D3DRM API is hardly pretty but it is a big improvement over D3DIM. D3DIM problems such as the execute buffer and capability bits are hidden from the application. It's conceivable that if Microsoft did in the future drop D3DIM then D3DRM could be rewritten without it.

D3DRM is based on the concept of frames. Each model has its own frame, loaded with polygon mesh and textures. Lights are placed in their own frame. The scene (the virtual world) and cameras each have their own frame. The application creates a hierachy by linking the models, lighting and camera frames into the scene frame. D3DRM will render the scene from the camera viewpoint.

Models can be loaded from disk (in Microsoft's ".x" 3d model format) or built from meshes in realtime. The texture wrapper function can take a texture and "wrap" it around a mesh. D3D lets the application specify rendering quality (eg. Gouraud shading) either by model or by scene.

No quantitative performance figures are available comparing D3DIM to the alternatives. The software renderer seems adequate, although some people have reported finding it is too slow.

General.

DirectX is still immature. The documentation and tutorials are not upto standard. Most of the example code is difficult to follow. Currently the only way to learn Direct3D is to sit down and analyse these line by line.

There is no compliance test for Direct3D. That is, hardware vendors can sell board they claim to be Direct3D compatible when infact they are only partially so. A Direct3D application might not run correctly on such a board. While this is technically the hardware vendors fault don't bet on a recall. Instead it will be up to the developer to rewrite their software to work around the missing or incorrectly-implemented features.

Developers porting existing applications will need to choose between IM and RM. Retained Mode's API has a structure that may not suit existing applications, requiring either redesign or using Immediate Mode instead.

Many hardware vendors have announced they will release Direct3D drivers with their graphics accelerator cards. This, and Microsoft's name mean that despite Direct3D's flaws it has a healthy chance of survival. However bear in mind that Microsoft doesn't always win; witness Microsoft's WinG API. While Retained Mode seems secure, Immediate mode is due for at the very least an overhaul. Microsoft is continuing work on a new version of DirectX.

Summary.

If you're willing to give up the freedom of being able to get stellar performance by applying your own graphics algorithms then Direct3D Retained Mode (D3DRM) would be the better choice.

Links.

• John Carmack of Id Software (the creators of "Quake" and "DOOM") sees some major problems with Direct3D Immediate Mode.
• Brian Hook of WK Software started writing a book on Direct3D before concluding it was fatally flawed.
• Mark Feldman of the Game Programmers Encyclopedia (GPE) gives a tutorial on using Direct3D Retained Mode.
• The Floating Point Game Developers Resource page has some good links on DirectX development.
• The DirectX SDK can be downloaded from Microsoft.

OpenGL 1.1

OpenGL is a technically strong graphics library. It offers a clean and well thought out API. It is low-level like Direct3D Immediate Mode, but without the design problems. (If you want high-level functionality like Direct3D Retained mode then you'd use eg. SGI's Performer library which lies on top of OpenGL. Performer is not included with Windows.)

Figure 2. An image from an OpenGL for Windows animation.

OpenGL has been around for a while. It's tried and tested: Many applications have been written in it. OpenGL is available on a wide number of platforms; from PCs to high-end SGI Reality Engines(tm). Vendors providing OpenGL implementations are forced to pass a conformance suite. This means if your application runs on one OpenGL implementation it'll run on any OpenGL implementation.

But OpenGL's problems aren't technical. They're marketing.

Silicon Graphics (SGI) is a company that for many years has enjoyed success selling high-end 3D graphics workstations. Applications running on these workstations used a graphics library called (aptly enough) "GL." Several years ago SGI took "GL" and turned it into an open standard; OpenGL.

Hardware vendors would license OpenGL from SGI and port OpenGL to their graphics card. Microsoft licensed OpenGL for Windows NT and produced their own port. This has been included free for NT for some time. It's now included in Windows 95 OSR2 which was released late 1996. (If you purchased Windows 95 earlier than this than you can download MS OpenGL for Windows 1.1 free of charge from Microsoft.)

Microsoft's initial port of OpenGL to Windows 1.0 was very slow. OpenGL for Windows 1.1 is faster, but still falls short of adequate performance. As an alternative SGI wrote their own fast software-only implementation of OpenGL, called CosmoGL (Officially "Cosmo OpenGL"). CosmoGL was supposed to debut in beta November 1996, but SGI decided to hold off releasing it due to a concerns expressed by Microsoft. Officially SGI are still working on CosmoGL, but no new release date has been announced. We note that SGI's Cosmo VRML plugin is going to use Apple's QuickDraw3D, not CosmoGL.

Microsoft's Stephen Wright admits Microsoft "does not worship at the altar of SGI," and that they licensed OpenGL to provide a way for high-end applications running on SGI boxes to move to NT.

Officially Microsoft claim there is no conflict between Direct3D and OpenGL. They claim Direct3D is a games API, and (from the Direct3D manual): "OpenGL is a precise 3D technology used for high-end CAD/CAM, modeling and animation, simulations, scientific visualization, and other exacting 3D-image rendering." This argument is unconvincing. OpenGL and Direct3D provide the same functionality. OpenGL could be used for games if its Windows implementation (written by Microsoft) was fast enough.

SGI have a potential for a conflict of interest here. They make their money selling high-end graphics workstations. If PCs were to attain good 3D graphics performance then sales of high-end SGI boxes might fall. SGI insist they are not threatened by this. They claim that sales of capable 3D PCs will spur developers to write their applications initially on SGI boxes, porting them to PCs later. We note that SGI has essentially ignored the PC market for some years. Instead of providing their own PC graphics accelerator card they decided to collaborate with Nintendo to beef up the Nintendo 64. SGI consider it Microsoft's responsibility to promote and fine-tune OpenGL for Windows. But Microsoft's strategy seems to be to bring applications to Windows by offering OpenGL, and keep new ones there by using Direct3D.

Currently Graphics accelerator vendors have been slow to support OpenGL, preferring to support Microsoft's Direct3D. Unless SGI can get vendor support then OpenGL for Windows will remain a software only renderer. Even if SGI release their reportedly fast CosmoGL they won't be able to compete with Direct3D applications using graphics accelerator hardware.

OpenGL for Windows software performance is currently inadequate.

Summary

Enough developers prefer OpenGL over D3DIM that if CosmoGL and hardware support was forthcoming they would probably use it. As of January 1997, CosmoGL is still unreleased and there is no sign of strong driver support by hardware vendors.

It's too early to predict the fate of OpenGL on the PC. At the moment writing a Windows game that runs only under OpenGL would be risky without the above issues being resolved. OpenGL will probably always have a share of the high-end graphics workstation market.

Update: See top of this article for a CosmoGL update.

Links

• SGI provides links to OpenGL resources at the OpenGL WWW Center.
• OpenGL for Windows 95 can be downloaded from Microsoft. Some Windows-specific calls are required to use OpenGL under Windows. These are documented and example code provided with Microsoft Visual C++ 4.0 Win32 SDK. Although the example code "CUBE" uses Microsoft Foundation Classes (MFC), the OpenGL is easily separate into a generic Win32 application. This SDK and this code may be bundled with other compilers such as Borland and Watcom.
• 3DLabs produces Graphics Accelerator cards with OpenGL Drivers.

QuickDraw3D 1.5

QuickDraw3D (aka Quick3D or Q3D) is Apple's implementation of a 3D graphics library. It's available free of charge for both Microsoft Windows and the Apple MacIntosh from http://quickdraw3d.apple.com . QuickDraw3D is a high-level graphics library, like Direct3D Retained Mode. It is built on top of Apple's low-level library named "RAVE".

Figure 3. A QuickDraw3D rendering of a Hatchback.

The image quality is exceptional in 24-bit mode (shown here). However in 8-bit and even 16-bit modes the images show distinct colour bands. (As I have not had time to fully read the Q3D documentation there may be ways around this I am not aware of.) QuickDraw3D 1.5 for Windows seems sluggish, even for simple 3d models.

All major graphics accelerator vendors have agreed to provide QuickDraw3D drivers. It is unclear if these drivers will also provided for Windows environments.

According to an SGI press release, SGI recently selected QuickDraw3D over their own CosmoGL as the rendering engine of their Cosmo VRML plugin for both the MacIntosh and Windows. (One source I spoke to at SGI disputed this.)

Conclusion.

Links

Recommendation.

• I've selected Direct3D Retained Mode for closer examination. I intend to evaluate it fully, exploring its speed and maintability.
• Keep an eye on OpenGL. If CosmoGL and hardware vendor support is forthcoming it could indeed survive the transition to the PC. Update: See top of this article for a CosmoGL update.
• QuickDraw3D may be worth a closer look if the driver support does extend to Windows. Remember that some Apple technology such as QuickTime has successfully jumped across to the PC platform.
• At this stage I would not recommend Direct3D Immediate Mode. Microsoft has been made aware of Immediate Modes shortcomings. We hope they address these in an upcoming release.

I'd like to hear constructive comments, practical experience and benchmarks. If you have any to share then please mail me. Flames to /dev/null (or any DoubleSpace drive ;-).

Enjoy!

Back to Beeje's Home page

Use the information in this document at your own risk.

LIMITATION OF LIABILITY: WE (BEEJE AND OUR AUTHORISED SUPPLIERS) OFFER NO WARRANTY OF ANY KIND EITHER EXPRESSED OR IMPLIED INCLUDING THOSE OF MERCHANTABILITY, NONINFRINGEMENT OF THIRD-PARTY INTELLECTUAL PROPERTY, OR FITNESS FOR A PARTICULAR PURPOSE. NEITHER WE NOR OUR AUTHORISED SUPPLIERS AND DISTRIBUTORS SHALL BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING,WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THIS DOCUMENT OR ANY SERVICE OR PRODUCT DISCUSSED HEREIN, EVEN IF WE OR OUR AUTHORISED SUPPLIERS AND DISTRIBUTORS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SINCE SOME JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THAT PARTICULAR LIMITATION MAY NOT APPLY TO YOU.