Is D3DX undesirable?
Author
Hi,
I was intrigued by the amount of code written by people which seems to replicate functions provided by the D3DX framework.
I was wondering why this is......
Is bespoke, specialist code quicker, with the D3DX code meant as a helping hand for students of D3D?
Or do the authors of directX do the quickest code?
Your thoughts appreciated!
Simon
D3DX Code is mostly optimised highly. The reason people write their own code is usually because they are not aware of the D3DX equivelent, this is certainly the case for me.
ace
ace
Author
Yeah, i know what you mean, even in my limited experience....
You spend ages pondering a problem only to find that the function D3DXdowhateverbetter() exists!
You spend ages pondering a problem only to find that the function D3DXdowhateverbetter() exists!
Another reason why some people don't use D3DX in the commercial world is due to cross platform development - for example PS2 doesn't have D3DX so most studios have developed their own "libraries of useful code" over the years.
I would still say it's beneficial to know how to implement each of the D3DX functions you use yourself - just so you understand what you're calling. For example I happily use D3DX functions for things like texture loading because they're as fast as I need and they save me from writing dull code that's already available, but I have written my own code to do the same in the past so I can write my own replacement if I need to port the code to a non-DirectX platform or if profiling shows D3DX to be a problem (very rarely has).
A big benefit of using D3DX is it's well tested (i.e. thousands of people developing with DirectX, hundreds beta testing it, millions of people using products that use D3DX).
I would still say it's beneficial to know how to implement each of the D3DX functions you use yourself - just so you understand what you're calling. For example I happily use D3DX functions for things like texture loading because they're as fast as I need and they save me from writing dull code that's already available, but I have written my own code to do the same in the past so I can write my own replacement if I need to port the code to a non-DirectX platform or if profiling shows D3DX to be a problem (very rarely has).
A big benefit of using D3DX is it's well tested (i.e. thousands of people developing with DirectX, hundreds beta testing it, millions of people using products that use D3DX).
Also, D3DX has implements some ground-breaking technology - for example, an entire pre-computed radiance transfer library. Additionally, D3DX has some really nifty mesh operations - but it's just a pain sometimes getting your data into an ID3DXMesh in order to use them. Microsoft pours a lot of resources into D3DX, making sure that it is up-to-date with the latest and greatest technology.
Like Simon stated, it's very important that you know what you are calling and what it does. The matrix and vector structures and functions are very optimize and quite useful - you just have to know how to use them first [smile]
On the subject of optimizations, here is a vintage D3DX thread. Have fun [wink]
Like Simon stated, it's very important that you know what you are calling and what it does. The matrix and vector structures and functions are very optimize and quite useful - you just have to know how to use them first [smile]
On the subject of optimizations, here is a vintage D3DX thread. Have fun [wink]
Personally I dont use it (For the cross-platformability reason stated earlier) but also because of the fact that D3DX has been put into an external DLL which, to the best of my knowledge, is not supposed to be re-distributed and therefore it requires users to go to the Microsoft site and download a new DLL, unless they have the SDK installed.
Needless to say, that's a bit of a pain. I dont know if this problem has been rectified yet, however, I haven't really been following it.
The other thing is that I'm not overly fond of using external libraries. I'm one of those 'Do everything yourself' guys, mainly because I know that if there's a problem anywhere I can go in and fix it, rather than having to work around it and possibly break compatibility with a different platform.
Needless to say, that's a bit of a pain. I dont know if this problem has been rectified yet, however, I haven't really been following it.
The other thing is that I'm not overly fond of using external libraries. I'm one of those 'Do everything yourself' guys, mainly because I know that if there's a problem anywhere I can go in and fix it, rather than having to work around it and possibly break compatibility with a different platform.
I'm not completely positive, but I think D3DX is linked at compile time. Regardless, I've had many non-developers run demos with no problems.
This issue came in with the February release that moves D3DX into a dll d3dx9_24.dll, then in April it is d3dx9_25.dll. It is only a pain for those who do not distribute the end user runtime with their apps. This applies to me because my stuff is generally downloaded and I assume the user has DirectX 9.0c on ther machines. Now they need DirectX9.0c + the correct D3DX dll. The simple solution is of course just to include the dll with your app however this is against the Microsoft license agreement...
Quote:Original post by Trip99
This issue came in with the February release that moves D3DX into a dll d3dx9_24.dll, then in April it is d3dx9_25.dll. It is only a pain for those who do not distribute the end user runtime with their apps. This applies to me because my stuff is generally downloaded and I assume the user has DirectX 9.0c on ther machines. Now they need DirectX9.0c + the correct D3DX dll. The simple solution is of course just to include the dll with your app however this is against the Microsoft license agreement...
Agree, PITA.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
