Hello.
As mentioned in one of my topics I was lately reading "Beginning DirectX 11 Game Programming" book, which introduced me to XNAMAth library and *.fx files, which are used to store shaders code.
As I always like to learn from many sources (I'm also studying MSDN and DirectX SDK samples) I was looking for some more sources of knowledge and I found http://www.rastertek.com. Author of D3D11 tutorials on this website uses D3DX10Math library and *.psh, *.vsh files for shaders.
I read in the book that D3DXVECTOR3 is old way of doing the same thing by XMFLOAT3, but now I'm a bit lost. What's better to do ? Should I store Vertex Shaders in *.vsh files and Pixel Shaders in *.psh files or maybe it just doesn't matter if I store them in one *.fx file ? Should I use XNAMath library or stick to D3DX10Math ?
I'll be much grateful for any help.
XNAMath vs D3DX10Math && *.fx files vs *.psh and *.vsh
There are a few things to consider:
1. D3DX is essentially deprecated at this point. The library is totally functional and there's nothing "wrong" with it per se, but it is no longer being developed. Any future updates will be for DirectXMath (DirectXMath is the new name for XNAMath), and not for D3DX.
2. DirectXMath is designed to map well to modern SIMD instruction sets (SSE2-4 and ARM NEON), and allows for high performance math code if used right. D3DX math can use older SSE instructions, but it does so in a sub-optimal way. One result of this is that DirectXMath has a steeper learning curve, and generally requires you to write more code since you have to explicitly load and store SIMD values. However it's possible to write a wrapper that simplifies the usage, if you don't care very much about performance.
3. DirectXMath can be used in Windows 8 Metro apps, and like I mentioned earlier supports ARM instructions. So if you ever want to release on Windows Store, you can't use D3DX at all.
With all of that said, my recommendation would be to go with DirectXMath.
Now when you talk about .fx files, what you're really talking about is whether or not you should use the Effects Framework. The Effects Framework has a bit of a weird history. It started out as part of D3DX, and was essentially a support library that helped you manage shaders and setting constants, textures and device state. Then in D3D10 it became part of the core API, and was moved out of D3DX. Then for D3D11 they moved it out of both, stripped out some functionality, and provided it as source code that you can compile if you want to use it. Once again there are a few considerations:
1. Like I said before the Effects Framework is a helper library that sits on top of D3D. It helps you manage shaders and states, but it doesn't do anything that you couldn't do yourself with plain shaders and core API's.
2. In D3D9 the Effects Framework provided a pretty good model for mapping to the shader constant setup used by SM2.0/SM3.0 shaders, as well as the render state API. For D3D10 and D3D11 it is no longer such a good fit for constant buffers and immutable state objects, at least in my opinion. Like I mentioned earlier certain functionality was stripped out for the Effects11 version, which also makes it less useful than it used to be.
3. Like D3DX you can't use it for Metro applications. This is because it uses D3DCompiler DLL to compile shaders and obtain reflection data, and this functionality isn't available to Metro apps.
Personally, I wouldn't recommend using Effects11. It's not really very convenient anymore, and I feel like you're better off just getting familiar with out how shaders, states, constant buffers, and resources work in the core API.
1. D3DX is essentially deprecated at this point. The library is totally functional and there's nothing "wrong" with it per se, but it is no longer being developed. Any future updates will be for DirectXMath (DirectXMath is the new name for XNAMath), and not for D3DX.
2. DirectXMath is designed to map well to modern SIMD instruction sets (SSE2-4 and ARM NEON), and allows for high performance math code if used right. D3DX math can use older SSE instructions, but it does so in a sub-optimal way. One result of this is that DirectXMath has a steeper learning curve, and generally requires you to write more code since you have to explicitly load and store SIMD values. However it's possible to write a wrapper that simplifies the usage, if you don't care very much about performance.
3. DirectXMath can be used in Windows 8 Metro apps, and like I mentioned earlier supports ARM instructions. So if you ever want to release on Windows Store, you can't use D3DX at all.
With all of that said, my recommendation would be to go with DirectXMath.
Now when you talk about .fx files, what you're really talking about is whether or not you should use the Effects Framework. The Effects Framework has a bit of a weird history. It started out as part of D3DX, and was essentially a support library that helped you manage shaders and setting constants, textures and device state. Then in D3D10 it became part of the core API, and was moved out of D3DX. Then for D3D11 they moved it out of both, stripped out some functionality, and provided it as source code that you can compile if you want to use it. Once again there are a few considerations:
1. Like I said before the Effects Framework is a helper library that sits on top of D3D. It helps you manage shaders and states, but it doesn't do anything that you couldn't do yourself with plain shaders and core API's.
2. In D3D9 the Effects Framework provided a pretty good model for mapping to the shader constant setup used by SM2.0/SM3.0 shaders, as well as the render state API. For D3D10 and D3D11 it is no longer such a good fit for constant buffers and immutable state objects, at least in my opinion. Like I mentioned earlier certain functionality was stripped out for the Effects11 version, which also makes it less useful than it used to be.
3. Like D3DX you can't use it for Metro applications. This is because it uses D3DCompiler DLL to compile shaders and obtain reflection data, and this functionality isn't available to Metro apps.
Personally, I wouldn't recommend using Effects11. It's not really very convenient anymore, and I feel like you're better off just getting familiar with out how shaders, states, constant buffers, and resources work in the core API.
Author
Thank you for so long and so satisfying reply. I read about DirectXMath on MSDN and as I can see it is built on top of XNAMath ? You mentioned in your post that DirectXMath is just a new name for XNAMath, so I imagine that they have just changed name and added few more things (I saw on MSDN that there are declarations from XNAMath in DirectXMath). Also you said that DirectXMath "allows for high performance math code if used right". Well, didn't XNAMath work similarly as DirectXMath is built on XNAMath ?
About Shaders. Hm, in that way why does Microsoft use Effect Framework in DX SDK samples ? I always thought that SDK is good base for knowledge.
About Shaders. Hm, in that way why does Microsoft use Effect Framework in DX SDK samples ? I always thought that SDK is good base for knowledge.
Yeah DirectXMath is just the new name for XNAMath, you can think of it as the latest version of XNAMath. Most of it is exactly the same as XNAMath, so the things I said about DirectXMath apply to XNAMath as well (including what I said about high performance math code).
If you look at the samples, you'll actually noticed that MS stopped using effects for the D3D11 samples.
If you look at the samples, you'll actually noticed that MS stopped using effects for the D3D11 samples.
...generally requires you to write more code since you have to explicitly load and store SIMD values.
Or if you are careful, you can use 16-byte alignment directives so that the variables you care about are automatically 16-byte aligned, thus allowing you not to have to explicitly load/store SIMD values. The "care" is in dynamic allocation; for example, if you have an STL container of SIMD values requiring 16-byte alignment, then you need to use custom allocators. If you have 16-byte-aligned members in a class/struct, you need dynamic allocation of that class/struct to produce 16-byte aligned memory.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
