Author : Promit Roy
Page : << Previous 4
addition to that, writing a decent software renderer is insanely hard, especially if you are doing it alone. I usually reason it out like this: If my end-users need to use a software renderer, then they use have a low-end system which doesn't have a video card with 3D acceleration (increasingly rare nowadays). If they don't have a 3D accelerated card, then it follows that the system is likely to be very slow as well. If their system is that slow, they won't be able to run my software renderer at any usable speed to begin with. If they want to play my game, they should get a decent computer. And the converse: If they have a high-end system which is powerful enough to smoothly run my software renderer, then logically they must have a very powerful system, which would certainly have a video card with 3D acceleration, so they won't need my software renderer anyway.
Ok, there are some advantages to using a software render, though they are few. While playing Half-Life and CounterStrike online, I noticed that the D3D and OGL renderers sometimes failed to 'turn on' after I paused the game and went to the menu. Also, the software renderer could turn itself 'off' very quickly. (The system I play Half-Life on is extremely powerful; your system might not actually run the software renderer at a decent speed.)
The Future in General
The graphics programming field has sort of flattened out in terms of development of new things. Everything that is out there is well understood, well documented, and well accepted. Finding out about a feature only requires going on the internet and using your favorite search engine, or downloading/ordering an SDK. But anyway, back to the future. (Back to the future? Get it? Ya know...the movie...ha ha). I think all eyes should be on the graphics hardware companies. They are doing all the new pathfinding. There is a lot for them to be done, and we have to wait for them, since it's our job to make what they design work. People at companies such as nVidia, SGI, 3D Labs, ATI, etc. are doing a lot of work, and it ought to be pretty cool. After the eternal Processor Wars, the graphics industry is probably the most interesting thing to watch.
Putting It All Together
There is a major battle going on in the Windows sector between Direct3D and OpenGL. If you are not writing for Windows platforms, then don't use D3D, because it won't run on those platforms. Instead, stick with OpenGL. If you ARE writing for Windows, well you have one tough decision to make. If you learn one API, it is quite easy to learn the other, since the essential concepts are the same. I personally learned both at the same time (please do not question my judgement on this). If you truly cannot decide, I have found a foolproof method of deciding. Find a coin. It doesn't matter what kind, as long as the top and bottom have different pictures on them. Now choose one side to be "Heads" and the other side to be "Tails". Toss the coin up into the air. When it lands, check which side is face up. If "Heads", learn OpenGL. If "Tails", learn Direct3D. Now what ever API you chose, using whatever method, stick with it! Graphics programming is not easy to learn! You will sometimes find your self in difficult spots and may feel discouraged. Under no circumstance must you think, "What if I had just learned the other API?" It truly does not matter in the end.
But we can't use Direct3D! John Carmack denounced it!
Many OpenGL advocates point to something Carmack wrote several years ago, trashing Direct3D. Only, that was during the days Direct3D 5. In a much more recent post on www.slashdot.org, Carmack said that with the new advances in D3D, it could no longer be ignored. Direct3D has to be used by programmers along with OpenGL.
I can't take it! Direct3D with all its COM crap and such huge code!
If you can't deal with long code like D3D you will do very badly in the game world. The same goes for COM and classes in general. I do however, concede the point that OpenGL will be a lot simpler for most people, at least in the beginning. If you do learn Direct3D though, remember that for a lot of the learning curve, it is 90% initialization code. The trick is to get the other 10% to work right. (Or use the Common Files; they are very nice too.)
Great Games: What do They Use?
I feel that it is only fair to tell you which APIs some games have used. All the Quake games used OpenGL. Carmack wrote those engines; it is called the Quake engine (amazing, isn't it?). Half-Life wrote support for everything. Earth 2150 (not really a great game, but graphically very advanced) wrote support for OpenGL and D3D. MechWarrior 4: Vengeance used only DirectX, but it was just Microsoft's way of showing off Direct3D8.0 anyway. All XBox games use D3D. (Other consoles are not really worth mentioning since they usually use their own custom APIs, though some - like the Playstation 2 - do support OpenGL in various formats.)
I hinted before that most modeling and animation programs use/prefer OpenGL. While this is true, many also provide Direct3D support, such as Discreet's 3D Studio Max and GMax. Chumbalum Soft's Milkshape however, does not. (This is a very advanced and very cheap editor; for those on a low budget it is a very good deal at 20 USD.)
I admit that the above quotes prove little. Even so, it is helpful to have some reference.
Miscellaneous Addenda
In this article, I considered only the DirectX Graphics part of DirectX. It is worth mentioning that DirectX also provides many other interfaces for working with sound, input, etc. OpenGL doesn't include any of this functionality, because it is a pure graphics library. When writing a game, however, you will need these tools. Fortunately, there are many technologies that can be used with OpenGL that provide this functionality. OpenAL provides a cross platform audio library. There's also OpenML, which has not yet been implemented, but when it's done, it'll be to OpenGL what DirectX is to Direct3D. Another increasingly popular library is the Simple DirectMedia Layer (SDL). Don't confuse this with any of the DirectX components. I like using SDL much more than the other common approach: using DirectInput/DirectMusic/DirectSound to do the extras. That to me seems to defeat much of the purpose of using OpenGL.
Wrapping up
That's about it, really. There's not really too much else to say on the subject. Hopefully this guide has given you a better idea of which API to use, or at least what to consider when choosing. Oh, yes, contacts. For comments, suggestions, and questions, email me at comments@zgx.cjb.net. For mistakes in this article, email me at woops@zgx.cjb.net. If you still feel the need to flame me, email me at flames@zgx.cjb.net. NOTE: I cannot receive attachments, so please do not send them!
This article is Copyright © 2002, last edited on February 27, 2002. Although you are free to save or print out this article for your own use, under no condition may you distribute it to others without written consent of the author (which I am, in fact, quite willing to give).
Editor's Note
The intent of this article is to provide beginners with an unbiased overview of the OpenGL and Direct3D APIs, presenting the facts so that they can make their own decision about which to use. The author has rewritten the article several times in order to remove inaccuracies and statements which could lead to the types of flame wars we're trying to end with this. I myself have made numerous changes to it for the same reasons. Still, if you feel that it still contains statements that are inaccurate or that suggest a bias for one API or the other, please let me know so that we can make the necessary corrections.
Dave Astle
Executive Producer
Page : << Previous 4