d3dx9_26: Add custom ID3DXEffect interface.

[Rico Schüller]

Am 28.09.2011 22:18, schrieb Erich Hoover:
> 2011/9/28 Rico Schüller<kgbricola at 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 at 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 
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