[3/8] d3d8: Use D3DRESOURCETYPE -> WINED3DRESOURCETYPE enum conversion function instead of implicit conversion (clang)

Frédéric Delanoy frederic.delanoy at gmail.com
Mon May 30 06:34:25 CDT 2011


On Mon, May 30, 2011 at 12:42, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote:
>
>> +static inline D3DRESOURCETYPE
>> d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{
>> ...
>> +        case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER;
>> ...
>> +static inline WINED3DRESOURCETYPE
>> wined3dresourcetype_from_d3dresourcetype(D3DRESOURCETYPE type) +{
>> +        case D3DRTYPE_VERTEXBUFFER: return WINED3DRTYPE_BUFFER;
>> +        case D3DRTYPE_INDEXBUFFER: return (WINED3DRESOURCETYPE) type;
>
> Those two cases are worth printing a FIXME. Just move the implementation to
> device.c (like d3dformat_from_wined3dformat) so you have a declared debug
> channel.

In a similar vein, there's also
+        case WINED3DMULTISAMPLE_NONE: return D3DMULTISAMPLE_NONE;
+        case WINED3DMULTISAMPLE_NONMASKABLE: return (D3DMULTISAMPLE_TYPE) type;

Does this also need to be moved to device.c?

> In the long run the resource type conversion should go away in almost all
> places, and those places that still need it(like CheckDeviceFormat) have to do
> the conversion on their own.
>
> (Sorry that I didn't send that with the feedback for patch 7, it took me a
> while to get around to reading it)

I should probably better resubmit the whole modified series with a
(try 2), right? Or only the modified ones, still using the original
[foo/8]
 series?

Frédéric Delanoy



More information about the wine-devel mailing list