On 23 September 2015 at 10:51, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato:
- HRESULT (__cdecl *volume_created)(struct wined3d_device_parent
*device_parent, void *container_parent, - struct wined3d_volume *volume, void **parent, const struct wined3d_parent_ops **parent_ops); + HRESULT (__cdecl *volume_created)(struct wined3d_device_parent *device_parent, + struct wined3d_texture *texture, unsigned int sub_resource_idx, + void **parent, const struct wined3d_parent_ops **parent_ops);
Is there a reason why you're passing the wined3d_texture container instead of the container parent? It doesn't matter too much because you can either do wined3d_resource_get_parent or d3d*_texture->wined3d_texture, but I think it is a needless change.
Not all d3d9 surfaces will necessarily have a corresponding d3d9 texture, and I'm not sure it's worth changing that. So in that regard this is fine. (But please fix the '*' placement.) Once you pass a wined3d_texture the container_parent parameter becomes redundant.
It seems the patch is bigger than it needs to be. You could just add unsigned int sub_resource_idx and keep the rest in place. Through struct d3d8_texture *texture inside struct d3d8_volume you already have access to the wined3d texture. With the addition of the sub resource idx you can migrate the volume methods one by one, and in the last patch that removes access to wined3d_volume drop struct wined3d_volume *volume from the callback.
Yeah, this. Patches should only do a single thing as much as possibly/reasonable. It's a shame you can't drop the volume/surface parameter from the callback in the first patch, but not so much of an issue. In fact, you don't even necessarily need to store the texture/sub_resource_idx everywhere in the first patch. You should probably start with introducing something like wined3d_texture_map() and using it for d3d11. Then the second patch could e.g. be to use wined3d_texture_map() in d3d9 as well, with the callback interface change being a logical consequence of that.