The previous "What Needs To Be Done With OpenGL" post (available here) made some suggestions that - in my opinion - would improve the state of OpenGL and make it an API worth considering again. I deliberately kept away from issues like future evolution and platform compatibility; in the case of the one I believe that the changes can be made now and in such a way so as to make them available to all current versions (say by rolling some of them into GLU); in the case of the other it goes without saying, and anyway I had always intended to focus specifically on Windows so that I could do a fair and like-for-like comparison with Direct3D.
I'm not of the "Direct3D Good, OpenGL Bad" mindset - in a lot of ways OpenGL remains a far superior API to Direct3D (procedural vs COM based is a matter of personal opinion and doesn't come into it). There are certain things that are also wrong with Direct3D, and to balance the argument a discussion of them is also required. That's what I'm here for today.
Stop using Direct3D as a Vista marketing tool
OpenGL has proven that most D3D10 features actually can in fact run successfully on Windows XP. There is no reason whatsoever for features like geometry shaders to be restricted to Vista, and the arguments supplied by Microsoft don't wash. Yes, they might want to sell as many copies of their OS as possible, and that's fair, but how about letting it succeed or fail on it's own terms, rather than giving it artificial leg-ups like this?
Keep the API consistent between versions
Every time a new version of D3D comes out it's almost like you have to learn a new API all over again. There's no graceful evolution, and legacy work becomes worthless. It can't easily port to the new version, and is of minimal value to coders looking for samples of something they are trying to implement.
DOCUMENTATION!
The current state of D3D documentation is a case of "when it's good it's very very good, but when it's bad it's horrid". There are far too many places where related information is not grouped together, and where a developer has to pull together info from multiple sources scattered throughout the help file in order to get a clear picture of something. My understanding is that MS documentation is written by technical writers following a spec, then reviewed by programmers who design the API. How about getting it also reviewed by someone who actually uses the API? With regard to the samples provided, it should be ensured that they actually compile and run as written, and that they use the core API instead of some sample framework - it's their job to document an API, not to show off how good their programmers are. Having to delve through 5 layers of abstraction just to find out how to draw a triangle (exaggerated example) is not what somebody trying to learn the API from their documentation wants.
Sort out some of the basic data types
The implementation of Matrixes in D3D sucks. A big one. Hard. In the core API you basically have to set up each row and column yourself - by hand. You have to perform your own matrix multiplications. The D3DX library helps a little, but it's still obscure enough to trip up someone who just wants to rotate an object (having to instantiate a vector class just to do this is OOP overkill too...). Likewise, it should be possible to draw a primitive by just passing individual vertexes one at a time; too much of D3D assumes that your data is already set up in the correct format it expects, and as a result it's potential for use in experimental work is reduced. Colours need to be standardised; use of ARGB here, ABGR there, BGRA in the other place, and RGBA elsewhere, and with no reliable correlation between the component ordering and the format used (e.g. one texture format is D3DFMT_A8R8G8B8 but it actually expects data in BGRA order; others don't) just leads to confusion.
Move some of the heavy lifting that programmers have to do back into the API or runtime
Here I'm talking about stuff like handling device resets, loading textures with data, gracefully handling API call failures, and so forth. Some of these should be handled automatically by the runtime without any programmer involvement required at all, others should have API calls merged - I'd love to see a D3D equivalent of glTexImage2D, which just created a texture object and filled it with supplied raw data (and even generated mipmaps) in one fell swoop. There's something like it in D3DX, but it needs to be rolled into the main API and made more flexible. It's great that D3D is more low-level than OpenGL and gives you more specific control over how things work, but sometimes you also want a quick and dirty.
Anyway, that's that. Some of these may already be in D3D 10 or above; I don't know as I don't have Vista and have no intention of ever installing it (Windows 7 on the other hand looks a huge improvement), and given the development strategy for D3D it's reasonable enough to say that there is no chance of anything like these ever appearing in D3D9. It should be obvious at a glance that most of these also relate to areas where D3D compares unfavourably to OpenGL.
One conclusion that can be drawn from this post and the previous one is that there is potential for a truly great 3D API that can be all things to all people, but neither D3D nor OpenGL are currently there. Each needs more evolution in the direction of the other to get close, but some of the central philosophies underpinning each may well prevent it from ever really happening.
0 comments:
Post a Comment