[PATCH 04/11] ddraw: Create the second texture for system memory bindable surfaces.

Henri Verbeet hverbeet at gmail.com
Fri Mar 5 12:36:50 CST 2021


On Wed, 3 Mar 2021 at 23:36, Paul Gofman <pgofman at codeweavers.com> wrote:
> +static void ddraw_surface_create_draw_texture(struct ddraw_surface *surface)
> +{
> +    DDSURFACEDESC2 *desc = &surface->surface_desc;
> +    struct wined3d_resource *draw_texture_resource;
> +    struct wined3d_resource_desc wined3d_desc;
> +    unsigned int i, layer_count, level_count;
> +    struct wined3d_texture *draw_texture;
> +    struct ddraw_surface *parent;
> +    unsigned int bind_flags;
> +    HRESULT hr;
> +
> +    if (!(desc->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY))
> +        return;
> +
Does that check do the right thing? Note that we add
DDSCAPS_SYSTEMMEMORY for managed textures, but these still have
WINED3D_RESOURCE_ACCESS_GPU set.

> +    if (FAILED(hr = wined3d_texture_create(surface->ddraw->wined3d_device, &wined3d_desc, layer_count,
> +            level_count, 0, NULL, NULL,
> +            &ddraw_null_wined3d_parent_ops, &draw_texture)))
> +    {
> +        WARN("Failed to create wined3d texture, hr %#x.\n", hr);
> +        return;
> +    }
> +
Passing "ddraw_null_wined3d_parent_ops" for the "draw" texture here,
and "ddraw_texture_wined3d_parent_ops" for the other texture, means
that the draw texture being referenced by wined3d won't prevent the
ddraw surface/texture from being released.



More information about the wine-devel mailing list