D3D Vs openGL,
a survivors thoughts.
By James Sharman.
A whole bunch of game developers recently got together and petitioned Microsoft on this issue your can read the letter and the list of signatories here. This is a very interesting development to the whole issue, Microsoft has always stated that they intend to listen to developers and this looks like a time when this is going to be tested.
Since hardware accelerators for 3d graphics started to appear in quantity the question of how to support them has been a hot topic. There are really two main methods of supporting hardware cards, firstly to use a custom library for a specific card such as the GLIDE library for 3dfx cards, or use a generic 3d library. Using custom libraries is by far the easiest way of programming an individual card and will almost certainly produce the fastest possible results. The problem however is that there is more than one hardware accelerator out there and this is not a viable solution for general support when your target audiance is comprised of large numbers of different hardware boards. The solution to this it would seem is to use a generic library, there a several about with the most referred to being Direct3D, openGL, BRender, Renderware and 3dr. Within the games market the war is being fought between Direct3D and openGL with Direct3D having a big lead in terms of market support despite openGL being a very mature API. One big talking point on this issue is that John Carmack of id software has publicly slated direct 3d in favour of openGL. You can read the statement from John Carmack that sparked the argument here.
There are a number of issues surrounding this argument. I will look at the four closest to my heart whilst leaving some the of the heavy technical discussions to Direct 3D Analysis "An OpenGl Perspective". Much of the following thinking comes from me having spent a very depressing time converting SWIV 3D to Direct3D.
Ease Of Use
The issue of ease of use with Direct3D is a very regularly quoted problem, the shear bulk of code required to get even the simplest of systems running is very daunting. For a quick example SWIV 3D has nearly 5 times more code dedicated to Direct3D compared to 3DFX's glide, this comes down largely to having to handle a large numbers of multiple cases for very aspects of landscape drawing and texture management. The architecture of Direct3D surrounds what are called execute buffers which are filled with groups of vertices, state changes and triangles before being 'executed' (The process of sending the data to the hardware device). One of the many complaints is that Direct3D has fixed structures that the developer is forced to use whereas openGL as mechanism for accepting vertex data in a verity of formats and type's. The benefit this gives is that the API can form it's way of working around the way the programmer thinks the code is best structured rather than the programmer having the structure of the data dictated by the API. The problem of having to form execute buffers in order to do the simplest of tasks has been partially addressed with the new Direct Primitive extension's to Direct3D (in DirectX 5), unfortunately this is just another layer on top of the Execute buffer paradigm that potentially introduces more overhead. The feature set that any given Direct3D driver supports is not guaranteed forcing the programmer to handle multiple cases in order to produce equivalent effects on cards with different features.
Conformance is perhaps the biggest argument in favour of openGL, the openGL API has what are known as conformance tests to ensure that all implementations give the same results for a given set of inputs. Direct3D however has absolutely no conformance testing at all and driver producers are free to interpret the driver specification freely. The Fundamental issue here is that under openGL a program that works on one driver can be virtually guaranteed to work in the same way with another, Direct 3D however essentially requires that the program be tested with just about every accelerator card in the market with numerous changes being made to the code to ensure compatibility. The extra workload this places on the developer is unacceptable, support for hardware is already adding a significant cost to the development of new products without this added expense both in development and quality assurance. The driver conformance issue is present to a lesser degree with standard texture mapped triangle types since Microsoft to have a standard set of demo's that the drivers will be expected to work with, however none of the demo's include any more complex functionality such as transparency or translucency. In these key areas that are what make hardware cards really excel over software implementations Direct3D falls flat on its face. The possible difference between two cards running the same bit of software would astound most users, it would obviously not be prudent for me to name names but some cards have incredibly poor drivers in this respect.
The Direct3D API has fixed specification's and already cards exist with significant functionality that is not catered for within the Direct3D specification. OpenGL takes a slightly different approach with an open standard for extensions to the driver interface that manufactures can use at will (These extensions may then be adopted by other manufacturers and then incorporated into the openGL specification). The pace of development in the hardware card market will not slow in the foreseeable future and Microsoft can't hope to keep up with this pace with new release of Direct3D. These leaves the industry in a possible stalemate where it is not cost effective for manufactures to improve the feature set of there cards since it maybe some time before a version of Direct3D is available that will be able to offer support.
When you think of computers it's very easy sometimes to look singularly at PCs, you must remember however that there are lots of architectures out there from consoles up to silicon graphics workstations. The openGL architecture is present in various forms on a massive range of machines as well as purely on PCs and has the maturity to insure compatibility. The Direct3D API however is and always will be limited to machines capable of running windows95 or windowsNT. In a time when we are trying to move away from architecture dependence Direct3D really is a step in the wrong direction. For a while now there has been a trend in the console market towards providing API's to speed development. Rumour has it that a number of manufacturers are looking at cut-down subsets of the openGL API to incorporate into their systems to provide simple paths of porting between architectures. If this were to happen it would provide a way out for developers from the expansion of the market into a vast array of different architectures and platforms.
Options For Microsoft
It would be nice if Microsoft admitted defeat on this one and looked at a way to rectify the situation. It would be of great benefit to the openGL interface on PCs if it were better tied to direct draw allowing better control over the drawing surface. We should remember that there are two API's in direct 3d, immediate mode and retained mode. Retained mode being the higher level system would be perfectly capable of sitting on top of openGL instead of direct 3D immediate mode. Direct3D immediate mode is the component part of D3D that is most comparable to direct 3D. I personally see this as a very amicable solution were Microsoft to take this route with them not having to abandon all of Direct3D whilst giving support to openGL.
My Personal Game Plan
When it comes to hardware accelerators we as developers can't afford to look away, hardware is a very important aspect of the games market now and we cannot afford to ignore it. It can be very rewarding to see your technology running at higher resolution, high speed and high colour as I found with the 3dfx conversion of SWIV 3D. Although what I actually do depends largely on the wishes and policies of my company at the time I intend giving as much support as I can to openGL and if possible providing support for the major non-compliant cards using custom API's, I also intend where possible to provide custom support for the most popular cards since this always will provide the best performance and quality. Unfortunately unless the market changes Direct3D is here to stay for a good while to come and it looks like there are a good few sleepless night ahead of those of us with the job of implementing the graphics engines of the next round of games to use it.
The force of the market unfortunately forces the path of developers. If the current trend of card manufacturers towards providing openGL drivers continues then it may become viable to develop directly for openGL as opposed to direct3D. If this occurs then it will almost certainly be a first in the industry in that a standard that started of with a massive lead in developer support is replaced by the second place API. Very few people will actually stick their neck out in support of D3D over openGL and most developers simply admit that they support D3D primarily because of the market dominance at this time. It will be interesting to see what Microsoft do to try and get themselves out of this problem.
|OpenGL Books and Papers||A good source of openGL information from the people who designed it.|
|Direct 3D Analysis "An OpenGl Perspective"||A damned fine read.|