Hello Rico, from d3d10misc.h of latest DirectX SDK:
// ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
d3dcommon.h seems to be an idl-generated header. From what I can see up to now, only your first patch is "wrong", the rest just needs to be fixed to include d3dcommon.h where needed. Now, I wrote an ID3D10Blob implementation too, it's almost exactly the same as yours (or, to be fair, both are mostly a copy, paste and replace of D3DXBuffer), but I defined the ID3D10Blob interface as latest SDK while you implemented some more things. My plan at this point is: I'll send in a bit a patch adding d3dcommon.idl with the relevant definitions, then you can rebase and adjust your patches on top of it. Does it sound good?
Matteo.
On 26 July 2010 21:21, Matteo Bruni matteo.mystral@gmail.com wrote:
// ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
Actually, since this comes up now, perhaps this is a good time to think about implementing d3dcompiler and d3dx10? I think we'll have to anyway at some point, and perhaps it's better to do this now instead of once there's much more code in d3d10.
2010/7/27 Henri Verbeet hverbeet@gmail.com:
On 26 July 2010 21:21, Matteo Bruni matteo.mystral@gmail.com wrote:
// ID3D10Blob has been made version-neutral and moved to d3dcommon.h.
Actually, since this comes up now, perhaps this is a good time to think about implementing d3dcompiler and d3dx10? I think we'll have to anyway at some point, and perhaps it's better to do this now instead of once there's much more code in d3d10.
Yes, this is the best time I believe. Some time ago there was agreement to implement the shader compiler in d3dcompiler, with the d3dx9/d3d10/d3dx10 compiler function calls forwarding to d3dcompiler. My plan for the immediate future is to stub out d3dcompiler_43.dll and then move the shader assembler there (forwarding D3DXAssembleShader to d3dcompiler's D3DAssemble, which is undocumented but "stable" in the last 3 DirectX SDK) to be able to reuse some assembler code for the compiler implementation. I have some patches in my local git, they just need a bit of cleanup. Should I proceed with my plan?
On 27 July 2010 16:37, Matteo Bruni matteo.mystral@gmail.com wrote:
Yes, this is the best time I believe. Some time ago there was agreement to implement the shader compiler in d3dcompiler, with the d3dx9/d3d10/d3dx10 compiler function calls forwarding to d3dcompiler. My plan for the immediate future is to stub out d3dcompiler_43.dll and then move the shader assembler there (forwarding D3DXAssembleShader to d3dcompiler's D3DAssemble, which is undocumented but "stable" in the last 3 DirectX SDK) to be able to reuse some assembler code for the compiler implementation. I have some patches in my local git, they just need a bit of cleanup. Should I proceed with my plan?
You should probably check with Alexandre to make sure, but makes sense to me. I think the effect parsing stuff doesn't interact too much with d3dcompiler, and should go into d3dx10.
2010/7/27 Henri Verbeet hverbeet@gmail.com:
On 27 July 2010 16:37, Matteo Bruni matteo.mystral@gmail.com wrote:
Yes, this is the best time I believe. Some time ago there was agreement to implement the shader compiler in d3dcompiler, with the d3dx9/d3d10/d3dx10 compiler function calls forwarding to d3dcompiler. My plan for the immediate future is to stub out d3dcompiler_43.dll and then move the shader assembler there (forwarding D3DXAssembleShader to d3dcompiler's D3DAssemble, which is undocumented but "stable" in the last 3 DirectX SDK) to be able to reuse some assembler code for the compiler implementation. I have some patches in my local git, they just need a bit of cleanup. Should I proceed with my plan?
You should probably check with Alexandre to make sure, but makes sense to me. I think the effect parsing stuff doesn't interact too much with d3dcompiler, and should go into d3dx10.
Will do. Not sure on the effect stuff: on http://msdn.microsoft.com/en-us/library/dd607324%28v=VS.85%29.aspx the D3DCompile input is described as "a pointer to uncompiled shader data; either ASCII HLSL code or a compiled effect", but some tests are required to see what that really means.
On 27 July 2010 17:04, Matteo Bruni matteo.mystral@gmail.com wrote:
Will do. Not sure on the effect stuff: on http://msdn.microsoft.com/en-us/library/dd607324%28v=VS.85%29.aspx the D3DCompile input is described as "a pointer to uncompiled shader data; either ASCII HLSL code or a compiled effect", but some tests are required to see what that really means.
Odd, I'd expect compiled effects to also have compiled shaders. If it's just about extracting the shader blobs that's easy though, you don't need a full effect parser for that.
-
Henri Verbeet -
Matteo Bruni