On 09/28/2011 11:03 PM, Rico Schüller wrote:
Am 28.09.2011 22:18, schrieb Erich Hoover:
2011/9/28 Rico Schüllerkgbricola@web.de:
... d3dx9_25 and 24 needs it's own implementation because it's not only the last function which changed and that way it would look the same for all forwarding effect interfaces in d3dx9_2{4,5,6}.dlls.
I'm not an expert on this area, but I'd be tempted to implement this by having everything go through d3dx9_36. I might be missing something, but it seems like you could easily declare different virtual function tables and switch to the appropriate one based on the GUID passed to QueryInterface.
Erich Hoover ehoover@mines.edu
That's possible but D3DXCreateEffect needs to return the correct effect interface for the corresponding dll, too. The D3DXCreateEffect in d3dx9_36.dll doesn't know anything about which version it should return. So at least that function is needed 3 times. Maybe a QueryInterface in D3DXCreateEffect25 after the D3DXCreateEffect call should do the trick, but it breaks native d3dx9_36.dll in that case or the interfaces still need to be known to 24/25, 26 and 36 dlls, but don't have to be public. Well that would really make the code a lot smaller.
Sure the possible problem with the "wrong" supported GUID would then affected all d3dx9_xx.dlls. I'm fine with both versions. The question is what's more important, compatibility or code size? From a quick look now
Not making a mess out of COM else it will come haunt you ;)
I don't think that the "compatibility issue" affects any app, but I couldn't prove it. I could only say, that only the corresponding interface is allowed by each dll.
bye michael