d3dx9_26: Add custom ID3DXEffect interface.

[Rico Schüller]

Am 29.09.2011 00:13, schrieb Erich Hoover:
> On Wed, Sep 28, 2011 at 2:45 PM, Alexandre Julliard<julliard at winehq.org>  wrote:
>> ...
>> In general it's better to have the individual dlls handle their own
>> differences, instead of requiring d3dx9_36 to handle all the quirks of
>> 20 different versions.
> It sounded like we were only talking about some functions not existing
> on older versions, but if that's not the case then I would definitely
> agree.
>
> Erich Hoover
> ehoover at mines.edu
>
Maybe I wasn't that clear about the topic. The effect interface from 
d3dx9_36 has one more function (SetRawValue) than the effect interface 
from d3dx9_26. Because of this difference the GUID is different. My 
proposed solutions are:

1. If we implement the GUID in d3dx9_36 it will break the usage of 
native d3dx9_36 on wine because native doesn't support that interface 
and the forwards will be broken. Of course you would be able to use 
native d3dx9_26 in that case, but I think that's tricky, because the 
user has to take care to choose the correct d3dx9_xx.dll for each app. 
An example where this would be problematic is CIV 4, it querys for the 
GUID26 which would fail if native d3dx9_36 is used (which is mostly 
needed for other missing functions for now). It also has the problem 
with the "small changes" as #2.

2. Make a wrapper for each ID3DXEffectInterface in d3dx9_xx.dll where it 
is needed. That way it works with native d3dx9_36.dll on wine. The 
wrapper includes the complete interface like it is done in my patch.
Problem: The problem I see with this is that there may be small 
differences within the d3dx9_xx.dll which may be hard to find, but 
that's a problem when reusing code which might have different versions 
on the native d3dx9_xx.dlls. This is a problem with all forwarding 
functions, but I don't think that's a problem we have now, because we 
don't know what's the specific difference, yet and the differences may 
be small enough so that they could easily handled.

3. We may use a wined3dx (as suggested by Luis) which could handle all 
GUIDs. That way it is possible to add a custom D3DXCreateEffect function 
which could return the correct interface. Well I would prefer that more 
than #1, but it has the same flaws and there would be the need to move a 
lot of code around.

4. Implement each version on it's own, so each dll would get it's own 
code base. This way all differences could be handled correctly.

Thus the only version which would really work 100% is #4, but due to not 
knowing the small differences and the huge amount of work which is 
needed, #4 seems to be practically out of scope. We have to switch to 
that later if we see no way to solve the version differences.
So I think the way with reusing the code like it is done now is more 
practically and #2 makes that really good. It doesn't break the current 
forwards and keeps the version specific stuff in the correct dll.
#1 seems to be a no go for me, because it breaks a lot more which just 
works now and that would annoy users a lot and we may get trouble with 
that one.

So definitively my preferred solution is #2.


#3 seem to be an improvement over #1. It has the advantage to cover more 
differences with a smaller code base, but it would also break the 
forwards to d3dx9_36.dll. So in general it only moves the problem a way 
further, but with the chance to make the implementation a bit easier 
(e.g. like with a custom D3DXCreateEffect function). Though using #2 and 
#3 would make it really good I think. The suggestion with the wined3dx 
may improve all ways and it may be possible to handle even the "small 
changes" with less effort, but I think that's a different discussion. 
Well I haven't found the answer for that in the devel archive but I 
found 
http://www.winehq.org/pipermail/wine-devel/2007-November/060662.html . 
Maybe someone else knows more about that topic.

Cheers
Rico