Am 18.04.2014 um 18:58 schrieb Henri Verbeet hverbeet@gmail.com:
I don't care about that ordering as much by itself. I do think that it makes more sense to approach this as removing surfaces and volumes from the public wined3d API than the approach you're taking here. I.e., instead of e.g. forwarding d3d9_volume_LockBox() to d3d9_texture_3d_LockBox() that then still does a wined3d_volume_map(), I think it makes more sense to introduce wined3d_texture_map(), get rid of wined3d_volume_map() and wined3d_surface_map(), and then let the rest just fall out as a logical consequence. Related to that, I think surfaces are the more interesting case to start with, because of things like e.g. wined3d_device_set_render_target(), and perhaps more importantly wined3d_device_get_render_target().
Merging surface / volume map in texture_map doesn’t work well without having a common (internal) sub resource interface that the texture can call. Unless of course I do a switch(texture_type) and forward this to the separate surface_map and volume_map internally.