Of DirectX and D3DX

I’m certain that I’ve written about this back in the days of yore but, slowly, as time went on, I actually began to trust and even like using the Direct D3DX utilities in my own codebase. I have generally only relied on the matrix, vector, and quaternion functionality early on in developing a codebase simply to the reliability of knowing that the D3DX math routines are fool-proof as opposed to the routines I could write on my own that may do something stupid like CVector::CVector( float x, float y, float z ) { x = x; y = y; z = z; } or something along those lines. Early on in the development of any engine or framework the kind of functionality that D3DX grants to programmers is incredibly useful as a launching point.

In the past my complaints about D3DX were that it was an unnecessarily bloated aspect of the DirectX SDK that contained some features which, really, should have been part of the core SDK from the beginning. For the most part, this complaint has been rendered completely invalid as of DirectX 10. The most notable inclusion in the core SDK from D3DX is that the shader compiler has been moved to the core runtime from its previous position in D3DX. In fact, as of now, it seems that the D3DX functionality in DirectX 10 has been vastly trimmed down from DirectX 9. The most-frequently used functionality is still present such as file importers (mesh and image) and math routines but, other than that (unless the documentation is just lacking), the D3DX library seems to be far more skeletal than it was under DX9.

The functionality migration from D3DX9 to D3DX10 is a cause for great happiness for me. Some of the routines that were present in D3DX9 do still exist in some capacity, as it has now been moved over to the DirectX Utility Toolkit (DXUT), but, most importantly, they’re not in D3DX or the core API. This move seems to indicate that D3DX has become more of a staple of the SDK than it was originally intended to be. When I started doing research on the file specifications for the X format the frequent reliance on D3DX became more apparent then I’d ever realized. Most of the code snippet or article that I found focused solely on using the format alongside the D3DX9 functionality that existed. The resources that didn’t use D3DX, instead, used IDirectXFile to parse the data as-necessary (this interface has now been deprecated). What’s more unfortunate is that some of these resources were actual published books and the contents of these articles are, as of DX10, fairly useless.

My disdain for prolific use of D3DX in any setting outside test cases for new codebases is most likely a result of my preference as a programmer to always use code that I don’t have to treat as a mystical black box. I like knowing not only what is going on underneath the hood of functions or classes but, also, to be have the option to optimize the code or erase extraneous functionality which is of no use to me. I have always been of this mindset as a programmer and, despite my recent tendency to actually rely on the D3DX math utilities, I don’t see that changing of my own volition.

TL;DR – I don’t like the frequent use of D3DX and I like the changes DirectX 10 introduces in relation to it.

Related Posts
Why Make Video Games?
GDC 2010 – Day 6
You must be logged in to post a comment.