Welcome to the The ProgrammersTalk Community forums.
You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!
If you have any problems with the registration process or your account login, please contact contact us.
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.
I just found this interesting article wrote by some people who's doing game development...
I can't say whether we this is really true or not, since I haven't dealt a lot of DirectX development, I would like to know what researchers responses about this article..?