Request for comments: d3dX : wined3d implicit enum conversion warnings and resolution

[Frédéric Delanoy]

Hi guys,

while trying to compile wine with clang, I get a whole bunch of
"implicit conversion from enumeration type FOO to different
enumeration type WINED3DFOO" (and conversely) warnings when an enum
value of type A is assigned to a var of enum type B.

In order to tackle those, instead of using (probably ugly) casts
everywhere, I put them in a "static inline" function in d3dX_private.h
(conv functions put in the header so inlining is possible everywhere,
so a potential performance impact is limited)

Originally, I intended to issue a FIXME("Unhandled/unrecognized
value...") in the default: clause of a switch statement to catch
values not in in the original enum's domain, but I couldn't find a way
to make FIXMEs work in a .h file 'cos of a macro expansion hell

I'm not quite sure however what the best solution is wrt performance,
so I'd like your comments on this

Some explanations:
*D3DPOOL and WINED3DPOOL have a full 1-1 mapping, so the conv
functions simply do a cast.

*D3DRESOURCETYPE and WINED3DRESOURCETYPE have *not* a 1-1 mapping, and
I present here 3 possible solution types:

D3DRESOURCETYPE =>
    D3DRTYPE_SURFACE  =  1,
    D3DRTYPE_VOLUME  =  2,
    D3DRTYPE_TEXTURE =  3,
    D3DRTYPE_VOLUMETEXTURE =  4,
    D3DRTYPE_CUBETEXTURE =  5,
    D3DRTYPE_VERTEXBUFFER =  6,
    D3DRTYPE_INDEXBUFFER =  7,
    D3DRTYPE_FORCE_DWORD = 0x7fffffff

WINED3DRESOURCETYPE =>
    WINED3DRTYPE_SURFACE = 1,
    WINED3DRTYPE_VOLUME = 2,
    WINED3DRTYPE_TEXTURE = 3,
    WINED3DRTYPE_VOLUMETEXTURE = 4,
    WINED3DRTYPE_CUBETEXTURE = 5,
    WINED3DRTYPE_BUFFER = 6,
    WINED3DRTYPE_FORCE_DWORD = 0x7fffffff

Type 1
---------
Identical semantics to direct assigment
All cases specified, even "obvious" ones (D3D_FOO <-> WINED3D_FOO),
using same enum value; non mapped values use the default: clause (e.g.
D3DRTYPE_INDEXBUFFER=7; no 7 enum val in WINED3DRESOURCETYPE)
Default clause: only used for values not in original enum

Type 2
---------
Same as v1 except obvious values aren't specified in a case:
Non directly obvious values (same enum val) can still be "highlighted"
(e.g. WINED3DRTYPE_BUFFER=6 ==> D3DRTYPE_VERTEXBUFFER=6)
Default clause: used for values not in original enum AND obvious values

Maybe more optimal than "type 1", but isn't that a micro/premature
optimisation?

Type 3
---------
Potentially more risky/invasive: conversion does not simply return value "as-is"
Semantics *changes* from direct assigment; some additional code
changes are necessary; could help centralise, though

e.g.
D3DRTYPE_VERTEXBUFFER=6 => WINED3DRTYPE_BUFFER=6
D3DRTYPE_INDEXBUFFER=7     => WINED3DRTYPE_BUFFER=6

Adapted code (directx.c):
-    switch(RType) {
-        case D3DRTYPE_VERTEXBUFFER:
-        case D3DRTYPE_INDEXBUFFER:
-            WineD3DRType = WINED3DRTYPE_BUFFER;
-            break;
-
-        default:
-            WineD3DRType = RType;
-            break;
-    }
+    WineD3DRType = wined3dresourcetype_from_d3dresourcetype(RType);

What do you think would be best?

Frédéric