[1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

[Henri Verbeet]

On 31 May 2011 12:50, Alexandre Julliard <julliard at winehq.org> wrote:
> I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but
> by defining it when necessary, i.e. if neither d3d8types.h nor
> d3d9types.h have been included already.
>
> This way d3d8 uses the d3d8 definition, d3d9 uses the d3d9 definition,
> and ddraw/d3d10/wined3d internals use the wined3d definition which is
> probably a superset of the others.
>
It's called WINED3DPOOL instead of D3DPOOL since it's a wined3d type,
but otherwise I think that's close enough to what we currently have
that it's practically the same.

Conceptually I think it makes sense to have a distinction between
wined3d types and e.g. ddraw types. For things like D3DPOOL that's not
strictly required since it has the same values in all d3d versions
where it exists, but e.g. format IDs are incompatible between
versions. In that sense calling it WINED3DPOOL instead of D3DPOOL is
mostly just a matter of consistency. On the other hand, perhaps the
more fundamental point is that I'm not so sure that "superset of all
d3d versions" is the correct level of abstraction for wined3d. I
suspect we'll see that break down a bit as we implement more of
d3d10/11, and perhaps also with some ddraw cleanups. (To pick a random
example, consider d3d10/11 sampler states vs d3d8/9 sampler states.)

Note that WINED3DPOOL is a terrible example though, since it should go
away in favor of d3d10 style CPU/GPU access masks in the medium to
long term anyway. Similarly, it makes much more sense to fix something
like IDirect3DTexture8Impl_GetType() by replacing most of the function
with just "return D3DRTYPE_TEXTURE;" instead of introducing the
d3dresourcetype_from_wined3dresourcetype() function. The existing code
should be perfectly valid C, though perhaps not all that pretty in
some places. Clang throws some warnings, but well, tough. It's not
very high on my list of things I want to spend time thinking about. At
this point we probably spent more time talking about it than fixing
those enum conversion warnings would ever save anyone. Except for the
cases that are obvious to fix / improve, I think it's probably best to
just leave it alone. Maybe it will go away if we ignore it.