Am 29.09.2011 00:13, schrieb Erich Hoover:
On Wed, Sep 28, 2011 at 2:45 PM, Alexandre Julliardjulliard@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@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