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