SetRawValue is at the end of the table, so it being extra will not influence any older application. So, you should be able to get the same functionality with way less code by adding that alternative GUID to the QueryInterface in d3dx9_36.
Erich Hoover ehoover@mines.edu
Am 28.09.2011 16:43, schrieb Erich Hoover:
SetRawValue is at the end of the table, so it being extra will not influence any older application. So, you should be able to get the same functionality with way less code by adding that alternative GUID to the QueryInterface in d3dx9_36.
Erich Hoover ehoover@mines.edu
Sure that's possible for d3dx9_26.dll, but native d3dx9_36.dll doesn't offer that GUID. I don't think that's much of an issue (because I don't think an app depends on this), but I found the solution with the forward a better one that also looks a way more compatible. Well, adding only the GUID would reduce the needed code a lot.
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.
Cheers Rico
2011/9/28 Rico Schüller kgbricola@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@mines.edu
Erich Hoover ehoover@mines.edu writes:
2011/9/28 Rico Schüller kgbricola@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.
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.
On Wed, Sep 28, 2011 at 2:45 PM, Alexandre Julliard julliard@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
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
2011/9/29 Rico Schüller kgbricola@web.de:
- 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.
It's probably not worth it if it's just a few functions and a couple of interfaces, but you could also create a static library like e.g. libwpp.
Am 28.09.2011 22:18, schrieb Erich Hoover:
2011/9/28 Rico Schüllerkgbricola@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@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
On 09/28/2011 11:03 PM, Rico Schüller wrote:
Am 28.09.2011 22:18, schrieb Erich Hoover:
2011/9/28 Rico Schüllerkgbricola@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@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
Not making a mess out of COM else it will come haunt you ;)
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.
bye michael
-
Alexandre Julliard -
Erich Hoover -
Henri Verbeet -
Michael Stefaniuc -
Rico Schüller