DirectX December SDK Changes

#1 Ok,

This directory issue just got annoying.

I seem to be getting different behavior in a Debug vs Release build in terms of the working directory for compiling the shaders.

Can anyone help me out here? I have no idea why it would be different.

Thanks
Todd

#2 Hum so your compiling TGEA with new DX SDK libs? Or just compiling FX shaders in the SDK?

#3 Hi Randy,

I rebuilt TGEA with the December DX SDK lib. When compiling the shaders in Release mode it uses the shader file as the working directory for finding #includes and in Debug mode it uses the working directory of the application.

I'll post a question on the DirectX dev list, but I wanted to see if anyone here was familiar with this type of behavior or to see if I was just doing something silly.

Thanks
Todd

#4 I havent spent much time with it, as we rolled back to October 2006 SDK for now. You could work around it by forcing a directory change with SetWorkingDirectory or SetCurrentDirectory (whichever the function is), before the compiler is called... but thats about it, otherwise you did more experimenting than I did

J

#5 Jeremiah,

Thanks. I will do some more with this and see what Microsoft has to say...
I'll post anything I find out here...

#6 Just let GG worry about it :)

Sometime driver updates drive me nuts when they break something that was stable.

If you want stability always use whatver DX ver they are using at GG.

But I do think there's nothing wrong with experimenting with latest.

#7 Hi Vashner,

Yeah, I generally wait before updating my SDK, but I am having some problems with the information reported by PIX and I was hoping that the latest would provide some improvments....it didn't. :)

I have reported the problem on the dx mailing list and one of the DX developers has indicated that they are looking into it....

I'll post any additional information here.

#8 The problem with letting GG worry about it, is that it might be awhile, unfortunately. As such, to "properly" move to the Dec DX SDK will require rewrite of all PS 1.1 shaders in ASM instead of HLSL (although 1.1 is a joke anyways)... and I'm not sure if GG will do that or not

#9 Note: The include fix will be done with ID3DXInclude. Working on the PS 1.x problem.

#10 Hi Pat,

Thanks for posting here. Would you mind elaborating a little on the include fix? Microsoft did not post a followup after indicating that they were looking at this problem. Are you saying that they got back to you and it will be fixed in the next SDK or that you are doing something in TSE to fix this problem?

Thanks
Todd

#11 Some of the work I've done on the Xbox 360 code required me to handle the relative paths of shader #include lines. ID3DXInclude is an interface which will let Torque process those paths and supply the data. This fixes the include issue, because it handles the paths and passing the data inside the include file to the D3DX shader compiler. I also saw that they are looking at this as a bug in the SDK (which I agree with).

I am currently waiting on an answer regarding the deprecation of ps_1_x and the EULA implications of including d3dx_31.dll so that we can use the 'D3DXSHADER_USE_LEGACY_D3DX9_31_DLL' flag for shader compilation. Right now, though, it's kind of in limbo.

I would recommend using the October SDK until these issues are resolved.

#12 Ahhh...

I should have realized you were doing your own include handler when you indicated you were using ID3DXInclude.

Thanks for the details!

Todd

#13 It's going to be a while before this is fully fixed - there are issues with setting up redistributables for end users with the December release as well. For now we recommend developing with the October 2006 SDK.

#14 Just a note, the next release of TGEA will *not* include the ID3DXInclude code as it was only there to work around the #include issue with December. Since the SDK has some bugs and unresolved issues, use October with TGEA.

I plan to re-evaluate this when the February and/or March DirectX SDK is out.

#15 Hum.. just drop the 1.x card support it's a joke anyway. 2002-2007 is basically 2.0 cards the ATI 9700 and 5200 Nvidia. Let the older junk burn... IMO.

If someone has a card older then a 9700 or a 5200 let them work with TGE 1.5...

#16 Pat, thanks for the info...

Vashner, if the flag is only used for shaders that are specified as SM 1.0, then it is a really small change to the code and there is no cost to those of us using SM 2.0 and up.

A much bigger issue, is adding Fixed Function support to TGEA. I would hate to see the valuable GG resources wasted on something like that (IMO).

Todd

#17 I understand. Just would be nice to be more uh "unified" to reduce all the fallback code etc. But like you said no biggie.

#18 Materials refactor is on the list down the road, not because it's not important, but because it requires some pretty major design changes, and a *lot* of design meetings. Part of it is also going to be the feedback from TGEA going 1.0 and getting more people working on it. A material should be artist-defined information which describes how he wants the object rendered. It is my personal feeling that rendering should consist of two major bits, the material, and the geometry. The material manages state information, and is entirely seperated from rendering code. Things which render, GUI controls, shapes, should manage geometry and only geometry, and let the material-instance manage everything else. This allows the material system to make decisions about how it should render, fixed function, shaders, etc. State management (for applicable states) on the material will allow for more efficent state setting on the Xbox 360, as well as look-ahead to DX10's state blocks.

This is all down the road quite a way, though. Just thoughts on the whole thing, and why we haven't tackled yet...because it's big.

#19 Yea figured it was on post launch roadmap. Like maybe with the new particle system that was also suggested.