Update to latest d3d compiler dll

[GoogleCodeExporter]

The new windows sdks have an updated hlsl compiler, which is apparently much 
faster. I

It would be really good to have a slim dx update with this, since I am 
experiencing some very long compile times(eg 10 mins plus).

Original issue reported on code.google.com by dbl...@fastmail.fm on 17 Apr 2012 at 2:17

• Merged into: #835

[GoogleCodeExporter]

As far as I can tell, the latest Windows SDKs are still in beta form, and 
additionally drop support for old APIs and D3DX. It's doable, but could be 
quite annoying for anyone who still wants to use the old functionality.

Original comment by Mike.Popoloski on 17 Apr 2012 at 2:58

[GoogleCodeExporter]

Fair enough, I will probably compile a custom version with support when I get 
time.

I guess future distributions and releases need some thought about how to 
support both new and old APIs + redists etc. 

Just wanted to add a comment saying this is something which is important, 
without updates for WinRT, D3D11.1 etc.

Original comment by dbl...@fastmail.fm on 17 Apr 2012 at 3:07

[GoogleCodeExporter]

Maybe it would be possible to allow runtime selection of the d3d compiler dll 
from the SlimDX API? (ie LoadLibrary/GetProcAddress)

Might make things easier if thats all that will be regularly updated by MS and 
ease problems with versioning. 

The app can then put its prefered compiler dll in its directory.

Original comment by dbl...@fastmail.fm on 17 Apr 2012 at 3:15

[GoogleCodeExporter]

I started a branch recently that removes old APIs and the D3DX dependency. 
Transitioning that branch to the new Windows Kit should be much easier.

Dynamic loading of the D3DCompiler DLL might work, though I'd have to check to 
make sure they didn't change function parameters or something.

Original comment by Mike.Popoloski on 17 Apr 2012 at 3:24

[GoogleCodeExporter]

Rolling into the issue on metro changes.

Original comment by Mike.Popoloski on 10 Sep 2012 at 2:05

• Changed state: Duplicate