<div dir="ltr">I've sent the mail with the changes requested (on this and patch 3), except for:<br><div><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> +        hr = IDirectDrawSurface_AddAttachedSurface(surface, ds);<br>
> +        IDirectDrawSurface_Release(ds);<br>
> +        if (FAILED(hr))<br>
> +            return hr;<br>
> +    }<br>
</span>You've overshot my suggestion for pre-attached depth stencils a bit.<br>
Now you no longer detach application-created depth stencils any more<br>
in case CreateDevice() fails, but you also don't detach a depth<br>
stencil that you attached.<br>
<br>
This may even be the correct behavior. If you want you can write a<br>
test (e.g. try to pass a color surface without DDSCAPS_3DDEVICE, but<br>
*with* a depth stencil attached. See if it is detached. Try to pass a<br>
color surface without DDSCAPS_3DDEVICE and see if a depth stencil is<br>
attached after the failing CreateDevice call), but I don't think it's<br>
worth spending much time on this.<br>
<br>
My suggestion is to detach if creating the IM device fails, but only<br>
if create_z_surface is TRUE.<br></blockquote><div>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.<br><br><br></div><div>Cheers,<br></div><div>Jam <br></div></div></div></div></div>