[PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

Henri Verbeet hverbeet at gmail.com
Thu Oct 1 10:42:02 CDT 2015


On 23 September 2015 at 10:51, Stefan Dösinger
<stefandoesinger at 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.



More information about the wine-devel mailing list