|
|
|
|
|
Direct3d Vs. OpenglEven though Direct3D and OpenGL are a lot more similar than they used to be, there are still differences, and as in all API wars, each side has its followers. A discussion of the most significant areas of debate follows. Ease of use Prior to version 8, Direct3D was known to be rather clumsy to use -- to do a state change, for instance, it required a number of complex operations. For example, to enable or disable alpha blending, one had to create a so-called execute buffer, lock it, fill it with the correct opcodes (along with a structure header telling how many opcodes the buffer contained and a special "exit" opcode), unlock it and finally send it to the driver for execution. In contrast, an OpenGL program would do a single "glEnable(GL_BLEND);" call. This model was rather frustrating for many programmers; the most famous example probably comes from John Carmack's .plan where he urged Microsoft to drop Direct3D altogether in favour of OpenGL. However, with Direct3D version 8, many changes were made, and Direct3D could not be called a clumsy API anymore. However, Direct3D and OpenGL still follow different paradigms -- Direct3D is based on Microsoft's COM technology and thus is in its heart object oriented (so every texture is an object, for instance). OpenGL does not have such a paradigm, but instead is known as a state machine accessed through simple C functions. Which one is ultimately "better" depends on a programmer's preferences. The OpenGL state machine may be wrapped with an object oriented programming interface as part of the game engine. Such an effort was carried out by SGI and Microsoft as the Fahrenheit graphics API, but the project was a failure. Direct3D tends to be closer to the hardware than OpenGL is. For instance, if a program is minimized and then restored, Direct3D users will get what is known as a lost device, meaning the program has to re-upload all textures, set all vertex shader constants etc. OpenGL does this transparently for the programmer, of course at the cost of less control. A Direct3D application could for instance pause the game while the upload is happening, which would be harder for an OpenGL game. A widely preferred way of using OpenGL is what OpenGL calls "immediate mode", which allows the programmer to enter vertices (or vertex attributes such as texture-coordinates or colors) to the current vertex-buffer one-by-one manner (e.g. "glVertex3f(1.0f, 2.0f, 3.0f);"), at the obvious expense of speed. This is a very convenient way of drawing simple things, but in practice it makes the rendering notably slower. This is the same method adopted in Direct3D 5, and then augmented in DirectX 8 with the addition of Vertex and Index buffers - effectively cached buffers of geometry that could be stored locally on the hardware for fast access by the GPU, avoiding a copy of data from the user mode application to the hardware. With the ability to provide data in an immediate fashion via the DrawPrimitiveUP/DrawIndexedPrimitveUP APIs and the buffered use of Vertex and Index buffers, the programmer could choose based on the need which approach to use. OpenGL 1.1 introduced vertex arrays (which perform vastly better than immediate mode for larger amounts of geometry), and a later extension introduced "vertex buffer objects" (VBOs) which are largely functionally equivalent to Direct3D's vertex buffers. Speed Shortly after the establishment of both Direct3D and OpenGL as viable graphics libraries, Microsoft and SGI engaged in what several pieces of literature regard as the "API" wars. This war, though often about structure, would also tend to break down into fundamental arguments about which API offered superior performance. Much of this was related to the fact that during this competitive time, both Microsoft's Direct3D and various implementations of SGI's OpenGL were relegated to software renderer implementations in the consumer market (due to the very high costs of graphics hardware at the time). Thus the ability for a specific library to outperform another often fell solely on the library itself and not third-party circumstances, such as a poor graphics card. Microsoft, who had created an implementation of both Direct3D and OpenGL for their platform, had marketed Direct3D as faster based on performance comparisons of the two APIs that had been completed in-house. At that time, the report had been considered true (with regard to Microsoft's two implementations) and regarded as fact on the Windows platform till the 1996 SigGraph (Special Interest Group on Computer Graphics) conference. At that time, SGI challenged Microsoft with their own implementation of OpenGL which (through use of various demos) showed that in many cases OpenGL performed at, or above, the capabilities of Direct3D. For SGI, this was a critical milestone as it showed that the lack of performance in OpenGL was not due to the structure or design of OpenGL, but rather due to flaws in the implementation. Since then, both sides have attempted to claim victory on various merits, though no sufficient proof to this date has been offered as to which API truly exhibits the best performance. Much of this is related to the fact that performance of an application lies as much on a programmers ability to write good code or the presence of solid hardware and drivers, as it does on the API itself. Thus, in the case of modern systems, the issue of API speed has become more and more insignificant. As of today, graphic-intensive applications have found themselves to be CPU-bound even on mid-level graphics hardware, or limited by slow IO access across other system components; because of this, the focus has shifted away from the API to the hardware end of computer graphics. As a result, the greater issues that APIs tend to face now fall along the lines of usability, simplicity and features instead of speed. Structure OpenGL's API, originally written for the then-powerful SGI workstations, includes a number of commands that are rarely used (typically only in "high-end" rendering situations). The API as a whole contains about 250 calls, but only a subset of perhaps 100 are useful in a gaming context. OpenGL never defined a useful subset to be used in these situations, a set of commands that really should be implemented in the hardware for best performance. MiniGL, developed by id Software, would have made a reasonable starting point, but the problem has since disappeared as modern cards support more and more of the API in hardware. Direct3D, on the other hand, was designed with a hardware abstraction layer from the start. This made it much easier to implement on gaming cards, and is likely the primary reason for its fast adoption in the late 1990s. The same separation of high and low-level API also makes D3D more suitable for implementing in software, although this is no longer a real concern. Extensions The OpenGL extension mechanism is probably the most heavily disputed difference between the two APIs. OpenGL has a mechanism where any driver can advertise its own extensions to the API, thus introducing new functionality such as blend modes, new ways of transferring data to the GPU, or different texture wrapping parameters. This allows new functionality to be exposed quickly, but can often lead to confusion as different vendors implement similar extensions with different APIs. Many of these extensions are periodically standardized by the OpenGL Architecture Review Board and possibly included in future OpenGL revisions. On the other hand, Direct3D is specified by one vendor (Microsoft) only, which leads to a more consistent API, but sometimes missing vendor-specific features. nVidia's UltraShadowhttp://www.nvidia.com/object/feature_ultrashadow.html technology, for instance, is not yet available in the stock Direct3D APIs at the time of writing. It should be noted that Direct3D also supports texture format extensions (via so-called FourCC codes), but they are little known and rarely used. For example when the new GeForce 256 graphics card came out in 1999, games like Quake III Arena could immediately use the Transform & Lightning feature with an OpenGL extension, whereas Direct3D games had to wait a while till the next version. Another example of the difference was the way in which newer graphics cards added support for pixel shaders (known on OpenGL as "fragment programs"). Under Direct3D there is a single "pixel shader 1.1" (PS1.1) standard which works on both the GeForce 3 and up, and Radeon 8500 and up. Under OpenGL the same functionality is accessed through custom extensions. In theory the Microsoft approach means a single code path can support both cards, whereas under OpenGL the programmer would have to write two separate systems. In reality things are not so simple. nVidia's implementation of shaders is tightly tied to a number of uncommon features of their cards, and so in reality the programmer would likely have to write two sets of code anyway. However, this situation only existed for a short time, second-generation pixel shading cards were considerably more alike, leading to Pixel Shader 2.0. At which point OpenGL introduced its own ARB-approved extensions for both vertex and pixel shader extensions (GL_ARB_vertex_program and GL_ARB_fragment_program). Portability For the most part, Direct3D is tied to one specific platform: Microsoft Windows. A partial port of the Direct3D API (and DirectX in general) has been implemented in WINE, and Microsoft itself supplies a modified version for Xbox development. But even considering these exceptions, Direct3D is so tightly integrated into the Windows that porting it to a non-Windows operating system is very difficult. In fact Microsoft once promised to deliver a version for the PowerPC-based Apple Macintoshes, but gave up, thereby killing game development on that platform until Apple standardized on OpenGL. OpenGL, on the other hand, has implementations available across a wide variety of platforms including Windows, UNIX-based systems, Linux, and the aforementioned Mac OS X. In general, almost all modern operating systems capable of rendering 3-dimensional graphics will have a native OpenGL driver of some sort, or access to OpenGL-compliant software renderer such as Mesa 3D. This makes Direct3D a more limiting choice; however, it is up to the programmer to decide if this "lock-in" is a problem or not. For instance, the games market on non-Windows computer platforms is rather slim at the time of writing, so for many games publishers this might not be a big problem. Low-end cards (such as the Intel Extreme Graphics line) tend to have better driver support for Direct3D than OpenGL; however both ATI Technologies and nVidia, by far the two biggest players in the market at the time of writing, have OpenGL drivers that range from plausible to excellent for all their modern cards (on both Windows and selected non-Windows platforms).
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|