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

[Frédéric Delanoy]

On Sat, Jun 4, 2011 at 23:50, Henri Verbeet <hverbeet at gmail.com> wrote:
> 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.

OK. In that case I'll just abandon this patch series altogether, since
it's probably a waste of effort anyway to try and get something in.
However, with or without warnings/clang, passing around non 1-1 mapped
enum values is still bad style IMHO, and erroneous values can still be
passed unnoticed.

>Maybe it will go away if we ignore it.
Definitely when some cleanup is eventually done, but that's an
orthogonal argument.

Frédéric Delanoy