Am 28.09.2011 22:18, schrieb Erich Hoover:
2011/9/28 Rico Schüller<[email protected]>:
...
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
[email protected]
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
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.
Cheers
Rico
