d3dx9_26: Add custom ID3DXEffect interface.
kgbricola at web.de
Thu Sep 29 03:29:29 CDT 2011
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
> 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
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
Maybe someone else knows more about that topic.
More information about the wine-devel