Hi,
It's not really about this patch, but I am curious what the plans about sharing code between the various d3dx?_* libraries are. I think a big amount of functionality can be shared among d3dx8.dll, d3dx9_*.dll, and propably d3dxof.dll and d3drm.dll.
I think this was discussed in the past, but I am not sure if there was any outcome. The solution chosen for d3d was to create an internal library wined3d.dll, and have the other libs call it. I guess something similar should be done for d3dx as well.
For non COM interfaces this is pretty easy anyway. We can rename d3dx8 to wined3dx at any time and just load the functions into a new d3d8 thunk using the .spec file, without any C code. So I guess we can leave things as they currently are and move over to a shared lib once non-math functions are implemented, or someone starts d3dx9_*.dll
Functions like D3DXCreateTextureFromFileA seem to be a bit harder. Since they take an IDirect3DDevice8 * interface pointer d3dx9 cannot use them as is. Making a shared implementation is also not quite possible because it would need a wined3ddevice then, but only d3d8.dll knows how to get a wined3ddevice from a d3ddevice8. Also, d3dx* would depend on wined3d then, which is propably not what we want.
David, do you have any plans regarding that?
As a sidenote, I really like your patches! The patches are small but still every patch makes sense for itself, and tests in every patch :-)
I will write a HLSL compiler at some point, and propably a shader assembler. This will be needed for a complete d3dx8 and d3dx9 implementation, as well as d3d10. I am not yet sure where to put it, but it could be a standalone lib in libs/, to allow using the compiler at build time, or just include it in wined3dx, if we decide to add such a library.
On 11/19/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Hi,
It's not really about this patch, but I am curious what the plans about sharing code between the various d3dx?_* libraries are. I think a big amount of functionality can be shared among d3dx8.dll, d3dx9_*.dll, and propably d3dxof.dll and d3drm.dll.
I think this was discussed in the past, but I am not sure if there was any outcome. The solution chosen for d3d was to create an internal library wined3d.dll, and have the other libs call it. I guess something similar should be done for d3dx as well.
For non COM interfaces this is pretty easy anyway. We can rename d3dx8 to wined3dx at any time and just load the functions into a new d3d8 thunk using the .spec file, without any C code. So I guess we can leave things as they currently are and move over to a shared lib once non-math functions are implemented, or someone starts d3dx9_*.dll
Functions like D3DXCreateTextureFromFileA seem to be a bit harder. Since they take an IDirect3DDevice8 * interface pointer d3dx9 cannot use them as is. Making a shared implementation is also not quite possible because it would need a wined3ddevice then, but only d3d8.dll knows how to get a wined3ddevice from a d3ddevice8. Also, d3dx* would depend on wined3d then, which is propably not what we want.
David, do you have any plans regarding that?
As a sidenote, I really like your patches! The patches are small but still every patch makes sense for itself, and tests in every patch :-)
I will write a HLSL compiler at some point, and propably a shader assembler. This will be needed for a complete d3dx8 and d3dx9 implementation, as well as d3d10. I am not yet sure where to put it, but it could be a standalone lib in libs/, to allow using the compiler at build time, or just include it in wined3dx, if we decide to add such a library.
Why not having the functionality of d3dx in wined3d, instead of having a separate d3dx library called wined3dx? I like the having all the common functionality of d3drm,d3dx8, d3dx9_* and d3dxof dlls at one place and for all the version dependent stuff, we keep it the respective dlls.
-- VJ
Am Montag, 19. November 2007 21:19:08 schrieb Vijay Kiran Kamuju:
Why not having the functionality of d3dx in wined3d, instead of having a separate d3dx library called wined3dx? I like the having all the common functionality of d3drm,d3dx8, d3dx9_* and d3dxof dlls at one place and for all the version dependent stuff, we keep it the respective dlls.
Because it is in a separate DLL in Windows. But it is an option to put it into wined3d.
Also, wined3d is quite huge. The stripped binary has 926 kb of plain code - no graphics, nothing. Also, it is preferable that d3dx* can run on Windows without wined3d. Having a wined3d.dll around is not a big deal as long as it works without actually using the low level d3d parts of wined3d.
I am not opposed to put d3dx things into wined3d, but I think it is nicer to have it separate.
-
Stefan Dösinger -
Vijay Kiran Kamuju