<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 7, 2016 at 4:19 AM, Stefan Dösinger <span dir="ltr"><<a href="mailto:stefandoesinger@gmail.com" target="_blank">stefandoesinger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 2016-08-06 23:36, Stefan Dösinger wrote:<br>
> My reading of this is that the depth surface wasn't cleared<br>
> (everything else would be very surprising). If the color surface was<br>
> indeed cleared this shows that native at some place expects your ugly<br>
> deed of removing the depth surface. If the color is not cleared it<br>
> and the clear call is completely ignored I'd say something is broken<br>
> somewhere and we shouldn't care too much about this corner case.<br>
</span>I guess I should have read the version 2 test before hitting "send"...<br>
<br>
The v2 behavior is somewhat weird. What's even weirder is that you<br>
didn't need any todo_wine to make it work in Wine (whereas you need the<br>
todo_wine for the "sane" v1 behavior). Our DeleteAttachedSurface<br>
implementation sets the wined3d DS to NULL, at which point a<br>
D3DCLEAR_ZBUFFER clear should return an error. Do you have any idea why<br>
the depth buffer is still cleared on Wine?<br>
 <br></blockquote><div>afaik wined3d should return a WARN in wined3d_device_clear showing that the depth surface is missing and fail on clear. But it seems that despite the depth surface being deleted that wined3d is still able to use that depth surface, which is definitely weird. I will dig more into this and post here as I find anything.<br><br><br></div><div>Cheers,<br></div><div>Aaryaman <br></div></div><br></div></div>