Author : Promit Roy
Page : << Previous 2 Next >>
all their methods. The syntax for this is horrible, so you probably don't want to even bother looking at it. The COM stuff in objbase.h knows to look for the implementation in a DLL that has been registered with Windows. Don't worry about registration of the DirectX COM components; that happened automatically when you installed your DirectX runtime. In addition to all the COM declarations you'll find a lot of #defines and #includes of other headers. The header d3d8types.h, for example, defines most of the data structures used for DirectX.
Strengths
Direct3D does some things extremely well. Two of its major strengths, added with DirectX 8, are Programable Pixel and Vertex Shaders. I won't go into detail about these, but suffice to say that they allow you to replace portions of the rendering pipeline with custom code. Shaders are written with a sort of graphics language that looks very much like assembly code. (Note that OpenGL supports vertex and pixel shaders as well, but it does so through extensions, and at present, graphics vendors have not agreed on a standard way of using them). On the other hand, only the newest graphics cards (such as the GeForce 3 or 4 or Radeon 8500) support pixel shaders. (Some older cards support vertex shaders).
Direct3D provides functions to enumerate exactly what graphics hardware is available on a system.
Direct3D's syntax and structure have evolved to a format that many developers believe is more intuitive than previous versions, making it easier to develop for than it used to be.
If you like object oriented programming, and COM in particular, you'll be right at home with Direct3D's interface.
The fact that DirectX uses COM provides a proven method to introduce change without breaking existing code. As a rule, a COM interface cannot change. While on the surface this may seem like a bad thing, it's really not, for two reasons. One, although a given interface cannot change, a new version of an interface can be created, which can change in any way desired. Two, since an interface can never be removed either, new versions of DirectX won't break games written for older versions. The old interface is still there, unchanged, and can still be used.
Weaknesses
DirectX is only updated every year or so, which is a little slow considering how fast the graphics industry moves. They make up for this somewhat by working closely with graphics vendors and adding support for things aren't yet available. Also, when new features are introduced, Direct3D offers a standardized way of accessing them.
D3D requires much more code to initialize the thing. With Direct3D8, the effect has been greatly reduced; it now takes about 200 lines to draw your first triangle, as opposed to 800 lines in Direct3D7. Also, D3D will require one to know much more about how everything works. To begin D3D will take more learning than OGL, but there will be nothing that you won't need to know in OGL eventually either. D3D also has very little portability. How much? None, really. How many times can you say "Windows"? Yep, that's all it does. Windows. Although this includes the X-Box (which will still require platform specific code, and isn't really an option for hobbyist or beginning developers anyway), it can be a real killer for people who want to write multi-platform code.
Direct3D is not an open standard. That means that Microsoft, and only Microsoft, has the final say about what gets included in a release, and if they make a bad decision, it stays that way for about a year. How successful Microsoft has been at "getting it right" is completely a matter of opinion.
Finally, writing a DirectX game, or using any COM component, in pure C can be difficult and lead to frustration. As you saw earlier, the C code for Direct3D is hardly intuitive.
Language Support
One of COM's specifications is that it is language independent. For a long time though, languages other than C/C++ were not supported. With DirectX 7.0, "out of the box" support was included for VB (it doesn't support pointers and such, so a new dll called dx7vb.dll was required.). As far as I know, D3D supports most major programming languages. (People seem to be very unsure whether Java can interface directly with Direct3D OR OpenGL; there is a wrapper called Java3D that allows you to interface with both that most people use anyway.)
The Future
There is not much to look forward to, really. I doubt Microsoft will ever make DirectX available on other platforms. As far as new features, Microsoft will probably continue to keep pace with hardware vendors, adding support for new common hardware features, but doing little to innovate.
Comments/My Advice
Direct3D is very useful for making Win32 games. It is made solely for Win32. Because Direct3D is only for Windows systems, it is usually not used for high-end graphics applications. Many graphics people prefer a Unix or SGI workstation; Direct3D does not (and probably never will) support those platforms. There is really nothing that Direct3D can do that OpenGL can't, but it has the advantage that you don't have to write vendor-specific code to take advantage of the latest hardware features.
Direct3D is a lot more complicated because it does not totally hide the lower level things from you, like OpenGL does. Obviously, simplicity results in a loss of flexibility. But is it flexibility you actually need? There are many more things to consider than you might have guessed.
OpenGL: The Hard Facts
OpenGL is popular among developers in many different industries. It provides a great deal of functionality, and has proven to be a stable API over the 10+ years of its existence. It was written about 10 years ago to provide functionality for the future as far as possible. Unfortunately, that future has come and gone.
History
OpenGL was originally developed in 1992 by Silicon Graphics, as a descendant of an API known as Iris GL for UNIX. It was created as an open standard (not open source, as some people incorrectly believe), and is available on many different platforms. (Now that you know what "Open" refers to, you may also wonder what the "GL" stands for; not surprisingly, it's "Graphics Library".) OpenGL is overseen by a committee known as the Architecural Review Board (ARB). The ARB consists of representatives from major companies involved with the graphics industry, including 3D Labs, SGI, Apple, nVidia, ATI, Intel, id Software, and yes, even Microsoft.
There are two major implementations of OpenGL for Windows: One from SGI version and one from Microsoft. The Microsoft version is based on the SGI implementation. Since the latter is no longer supported, it is recommended that you use the Microsoft version. It corresponds to OpenGL 1.1, but there are no newer headers and libraries available anywhere else (you can, however, access newer OpenGL features using the extension mechanism, which is beyond the scope of this article).
There is another, unofficial OpenGL implementation available known as Mesa3D. I haven't actually tried it, but it is very stable, it's open-source, and it's available on many platforms. The creators of Mesa3D do not own an OpenGL license, so it cannot legally be called an OpenGL implementation, but it uses the same syntax. The only disadvantage to it is that it cannot always take full advantage of hardware.
OpenGL has been used for many years in all different sectors of the tech industry. It was developed from the beginning with a clear vision of the future, and as such, it has remained stable and consistent. On the other hand, the way the ARB operates has caused the core OpenGL specification to evolve relatively slowly. For years, this was fine, since it was designed for high end graphics workstations using professional level graphics cards. But as consumer level cards have caught up with and surpassed that which was cutting edge 10 years ago, developers have been required to rely on the extension mechanism more and more to keep up with new hardware features. Extensions are powerful, but they can make for very messy code. The ARB seems to recognize this problem, and is now updating the core specification more frequently.
Structure
OpenGL is, at its core, a state machine which controls how primitives are processed and rendered. It uses a procedural model (i.e. functions) to modify the state machine and pass data to it. Due to the high efficiency of this mechanism, code is usually short and (usually) easy to understand. This makes it easier to debug. Although OpenGL itself is procedural, it can be used in linear, modular, or OOP fashion equally easily; the choice is the programmer's. OpenGL also conceals a lot of detail about specific hardware devices and such from you. Most basic operations are very easy to do. Rendering is done between the calls glBegin and glEnd.
All OpenGL functions use a naming convention that looks like glFunctionName[argtypes]. An example of an OpenGL style function would be glVertex3f. "gl" tells you that it is an OpenGL call. "Vertex" tells you that
Page : << Previous 2 Next >>