December DirectX on Downloads
Author
Just noticed that they posted up in the last 2 hours the new Dec DX SDK.
http://www.microsoft.com/downloads/details.aspx?FamilyID=05da7623-f2f9-4f57-91aa-6db27fb8305f&DisplayLang=en
Hopefully the link will work.
edit: linked it up after reading up the faq. Apologies to everyone.
[Edited by - Xrystal on December 13, 2006 10:30:23 PM]
For those of you interested in what's new:
- D3D10 RTM release
- A few D3DX10 functions
- PIX features/fixes
- New HLSL compiler (no 1.x support)
- D3D10 RTM release
- A few D3DX10 functions
- PIX features/fixes
- New HLSL compiler (no 1.x support)
This is rediculous:
New HLSL Shader Compiler for Direct3D 9 Targets: No Support for 1.x Pixel Shader Targets
The December 2006 SDK includes D3DX9_32.DLL. This DLL includes the Direct3D 10 HLSL compiler enabled for Direct3D 9 targets (shader models 2.0 and later). The new compiler has no support for 1.x pixel shader targets. This new compiler is the default for Direct3D 9. As a result, all developers are encouraged to author their shaders in HLSL and use shader models 2.0 and higher. The legacy compiler is available using the /LD switch.
The new compiler exposed has the following issues:
* Using asm_fragment blocks is not supported by the DLL. Compilation of shaders or effects containing these statements will fail.
* Because only a subset of HLSL optimizations and new features are active in this release, generated shaders will not be fully optimized.
Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?
New HLSL Shader Compiler for Direct3D 9 Targets: No Support for 1.x Pixel Shader Targets
The December 2006 SDK includes D3DX9_32.DLL. This DLL includes the Direct3D 10 HLSL compiler enabled for Direct3D 9 targets (shader models 2.0 and later). The new compiler has no support for 1.x pixel shader targets. This new compiler is the default for Direct3D 9. As a result, all developers are encouraged to author their shaders in HLSL and use shader models 2.0 and higher. The legacy compiler is available using the /LD switch.
The new compiler exposed has the following issues:
* Using asm_fragment blocks is not supported by the DLL. Compilation of shaders or effects containing these statements will fail.
* Because only a subset of HLSL optimizations and new features are active in this release, generated shaders will not be fully optimized.
Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?
Good catch Xrystal - stickied [grin]
The other files (from here):
Also, whether you buy it as a reason or not, there is no requirement to install an updated SDK. In fact, if you're mid-project then its probably a bad idea full-stop. With that in mind, anyone bothered about the HLSL compiler (and SM1 targets) should stick with whatever SDK they've already got....
I'd imagine its because the SDK is not a compulsory upgrade that they're happy with putting new and not quite finished components in as defaults...
Cheers,
jack
The other files (from here):
- DirectX End-User Runtimes Web Installer
- DirectX End User Runtimes (December 2006) Full Download
- DirectX SDK - December 2006 : Symbol Files
Quote:Original post by relthamI've yet to check the details, but I'm pretty sure there is a flag to force the older HLSL compiler instead of the new D3D10-generation one.
Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?
Also, whether you buy it as a reason or not, there is no requirement to install an updated SDK. In fact, if you're mid-project then its probably a bad idea full-stop. With that in mind, anyone bothered about the HLSL compiler (and SM1 targets) should stick with whatever SDK they've already got....
I'd imagine its because the SDK is not a compulsory upgrade that they're happy with putting new and not quite finished components in as defaults...
Quote:I have the perfect summary of the december SDK: Mostly useless.Well if you're doing D3D10 work (as I am) then the Vista RTM compatability is a pretty useful addition [smile]
Cheers,
jack
For new titles, that still need to support SM1 (and FFP). I think it's unreasonable to expect us to stay on old SDK versions. Too much is enhanced and fixed. You are the second MVP type to say that, and it makes me wonder why you guys think it's ok to stay on old versions? I think it's terrible to stay on old versions.
You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling.
The new compiler (when finished) will be REALLY nice for SM2+ stuff, it should include SM1 in HLSL (not just ASM). And the flag to use the old compiler isn't very friendly since I'd have to maintain a seperate FX file with the SM1 techniques in the OLD fx format, while having SM2+ stuff being in the new format to gain the benefits of the new compiler and fx sharing between D3D9 and D3D10 (which should be possible and desirable since we already have to build 2 engines, sharing the fx files would make it a little less painful).
Maybe I'm alone in making a renderer that supports SM1 thru SM3 on D3D9 and SM4 on D3D10. I guess it's two renderers really, but anyway. I'll likely even support FFP if I can.
Not everyone is making a FPS that targets uber gamers only with high end gear.
You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling.
The new compiler (when finished) will be REALLY nice for SM2+ stuff, it should include SM1 in HLSL (not just ASM). And the flag to use the old compiler isn't very friendly since I'd have to maintain a seperate FX file with the SM1 techniques in the OLD fx format, while having SM2+ stuff being in the new format to gain the benefits of the new compiler and fx sharing between D3D9 and D3D10 (which should be possible and desirable since we already have to build 2 engines, sharing the fx files would make it a little less painful).
Maybe I'm alone in making a renderer that supports SM1 thru SM3 on D3D9 and SM4 on D3D10. I guess it's two renderers really, but anyway. I'll likely even support FFP if I can.
Not everyone is making a FPS that targets uber gamers only with high end gear.
Scaling from FFP to SM4 is a big aim and most of the bigger games you noticed stay away from the effect framework to reach it. They have implemented their own that work better with their own tool chain.
I know that would not help you. Maybe the D3D10 multistream example could ease your pain a little bit. It shows how the preprocessor could be use to use both FX file formats in one file.
But I agree that adding support for at least ASM PS 1.1-1.4 to the new format would be a good addition.
I know that would not help you. Maybe the D3D10 multistream example could ease your pain a little bit. It shows how the preprocessor could be use to use both FX file formats in one file.
But I agree that adding support for at least ASM PS 1.1-1.4 to the new format would be a good addition.
In the case someone is interested. A header comparison show some more changes than the “What’s new” includes:
http://gpu-fun.spaces.live.com/blog/cns!FB5EEACE075E1350!225.entry
http://gpu-fun.spaces.live.com/blog/cns!FB5EEACE075E1350!225.entry
Quote:Original post by relthamYes, I can see how my thoughts wouldn't be universally agreed upon [smile]
For new titles, that still need to support SM1 (and FFP). I think it's unreasonable to expect us to stay on old SDK versions. Too much is enhanced and fixed. You are the second MVP type to say that, and it makes me wonder why you guys think it's ok to stay on old versions? I think it's terrible to stay on old versions.
My main thought is that upgrading "for the sake of upgrading" is not a sensible option. If you're just seeing announcements every 2 months to a new version and automatically and blindly ripping out your existing one and dropping in the new one just because then that doesn't seem sensible.
If you're mid project or if you have some stable technology based on a particular release of the SDK then changing your SDK is equally a risky idea. At the very least you'll need to re-test components to ensure they work as intended, at worst you could end up spending time upgrading any code that relies on API parts that have changed between SDK's (which is rare lately, but it has happened in the past).
With respect to the latter point (which I think is the case here) then there needs to be a very strong reason for changing your tools mid-project. Is there a show-stopping bug in your current SDK that is now fixed? Is there a brand new feature that you just cannot live without? I suppose you could say it's the "risk versus reward" argument - the risk that something they've changed might break my existing code versus the reward I might get from some bug-fix or cool new feature.
Anyway, that's how I look at it and that's why I have said on several occasions that changing the SDK is not always a good idea. It's fine by me if you see things differently [smile]
Quote:Original post by relthamBaring in mind that the HLSL compiler was never amazing at the ps_1_x targets (it was okay with vs_1_x) I do fully appreciate that supporting the older generation of hardware is still important. Especially given that some SM2 hardware (*cough*GeForceFX*cough*) weren't so good at SM2 and in practice need to be run as high-end SM1 parts...
You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling.
Registering your point of view is always a good thing, maybe the powers that be will listen and act on it. But as far as we currently know, if you want the nice shiny D3D10 generation compiler you lose SM1 support. With that fact in mind it seems to me that sticking with the older generation SDK is your only option - given that you need an RTM SDK for your D3D10 engine it may even mean you have to split your code across builds against two SDK's. Not nice. But as Demirug posted - scaling across the hardware as you're attempting is no easy thing to do!
Quote:In the case someone is interested. A header comparison show some more changes than the “What’s new” includes:Nice summary. Thanks [grin]
http://gpu-fun.spaces.live.com/blog/cns!FB5EEACE075E1350!225.entry
Jack
Really noob question here, am I right in assuming if I use dx10 only in my engine that it will not run, or run very badly, on dx9 hw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
