On 10 September 2016 at 18:47, Fabian Maurer dark.shadow4@web.de wrote:
On Saturday, September 10, 2016 6:33:04 PM CEST you wrote:
Unfortunately d3dx dlls shouldn't depend on wined3d either. We've typically handled sharing across different versions of d3dx using PARENTSRC.
I see, what's the reason behind this? After all, d3dx_36 depends on d3d9 which in turn depends on wined3d. Just curious, I'll make it different if this is your standard.
In the first place it's conceptual, wined3d is Wine's equivalent to the D3D driver interface, it shouldn't be concerned with high-level utility functionality like D3DX. Second, and related, as Michael mentioned, Microsoft's d3dx9 doesn't depend directly on the D3D driver interface. You can use Microsoft's d3dx9 on Wine, and ideally you should be able to use a Win32 build of Wine's d3dx9 as a drop-in replacement on Windows, without additional dependencies.
I can put the conversion functions in dxgi and make it public by using the .spec file, but I really don't know about the actual texture loader.
DXGI isn't really the right place either, for similar reasons. In general, we'd like to limit the number of Wine-specific exports.
I mean, I could make a copy from all the d3dx9 code for d3dx11, but it seems more logical to not just duplicate code. But where would I put the code to use it in both d3dx9 and d3dx11? A new folder d3dx_shared for PARENTSRC?
It's largely up to Matteo and Alexandre, but I think there are a few options. We could for example use a single PARENTSRC for d3dx9/10/11. That would still require some thought, since while I'd expect many things to be similar or the same between d3dx9/10/11, there are also a considerable number of differences. Another option could be a static library like libwpp or libwine_port, although that's not a popular option. Maybe it's warranted for d3dx. Maybe there are other options as well.