[WINED3D] QueryInterface corrections
stefan at codeweavers.com
Sun May 7 05:11:22 CDT 2006
> > Well, WINED3DERR_INVALIDCALL == D3DERR_INVALIDCALL. I've added those
> > return values to the wined3d headers so I can check in ddraw for the
> > return values. A lot of retvals from wined3d are in d3d8 / d3d9 and do
> > not exist in ddraw.
> > Just wanted to point that out.
> > Stefan
> Yes, it does work. But it's still technically wrong, just like S_OK vs
> WINED3D_OK is. The correct way would be to translate wined3d return
> codes in d3d7/8/9, although it could be considered a bit excessive.
In ddraw I have to do that, because some return values are different, e.g.
WINED3DERR_INVALIDCALL vs DDERR_INVALIDPARAMS. I will code code a small macro
which translates the different values, with a default of just returning the
wined3d number. This could be put in d3d8 and d3d9 as a no-op macro / inline
function, and be extended if needed. If you look at the GetDC patch I sent
yesterday, it returns DDERR_DCALREADYCREATED to give ddraw more information
about the error. This doesn't exist in d3d8 and d3d9, which should return
D3DERR_INVALIDCALL in the same situation.
I have quickly created this function:
case WINED3DERR_INVALIDCALL: return DDERR_INVALIDPARAMS;
default: return hr;
If you remove the first case clause the compiler should optimize it away with
-O2, at least in my small assembler program it simply ignores the call, and
doesn't inline any code. When this is in place, there's a easy place to add
return code translation if needed.
BTW, our d3d8 and d3d9 libraries know about the ddraw return codes because
I've included the ddraw.h file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060507/b23cf42b/attachment.pgp
More information about the wine-devel