[PATCH 7/8] d3drm: Implement IDirect3DRMDevice::CreateDeviceFromSurface.

[Aaryaman Vasishta]

I've sent the mail with the changes requested (on this and patch 3), except
for:


> +        hr = IDirectDrawSurface_AddAttachedSurface(surface, ds);
> > +        IDirectDrawSurface_Release(ds);
> > +        if (FAILED(hr))
> > +            return hr;
> > +    }
> You've overshot my suggestion for pre-attached depth stencils a bit.
> Now you no longer detach application-created depth stencils any more
> in case CreateDevice() fails, but you also don't detach a depth
> stencil that you attached.
>
> This may even be the correct behavior. If you want you can write a
> test (e.g. try to pass a color surface without DDSCAPS_3DDEVICE, but
> *with* a depth stencil attached. See if it is detached. Try to pass a
> color surface without DDSCAPS_3DDEVICE and see if a depth stencil is
> attached after the failing CreateDevice call), but I don't think it's
> worth spending much time on this.
>
> My suggestion is to detach if creating the IM device fails, but only
> if create_z_surface is TRUE.
>
As discussed, when CreateDeviceFromSurface returns an error (say, on
passing a surface without the 3DDEVICE flag) it'll keep the depth surface
it created internally attached, without detaching it from the
application-created surface. This bug is apparently not mimicked in Wine's
ddraw implementation of AddAttachedSurface, where it will return an error
if you attach a z-buffer to a surface without the 3DDEVICE flag. This
behavior hasn't been tested on windows yet. We'll probably need to fix this
in ddraw and also extend the tests accordingly.


Cheers,
Jam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150807/cfec8bd7/attachment.html>