[PATCH 2/2] d3drm: Implement IDirect3DRMViewport*::Clear.

[Stefan Dösinger]

On 2016-08-07 00:28, Aaryaman Vasishta wrote:
> At that point the surface is already cleared to red color (see the test
> above clear_depth_surface call here) and the depth test fails while
> drawing the quad, so even if the clear was ignored, the color would
> remain the same as if it was cleared. Hmm but if I use the new z-coords
> that you specified above, then it's possible.
That's why I said "Also clear with a different color than what's left
behind by the previous test".

>> Can't the "where does the color come from" test be merged into the
>> clear test at the start?
> 
> It can. I just wanted to keep it separate 
I'd prefer to merge them, it will keep the overall test shorter and
improve readability IMO. It's a mild preference though, feel free to
keep them separate if you feel otherwise.

>> Do you need to draw with IDirect3DDevice2 directly here? What about
>> QI'ing IDirect3DDevice and calling d3d_draw_quad1? 
> 
> Not really. I just thought that since d3drm is giving us access to
> IDirect3DDevice2 here, might as well use it directly. I could QI version
> 1 and use d3d_draw_quad1 if you want, though.
That's a reasonable point. An application may do something similar, so
it's worth mixing IDirect3DDevice (d3drm internally) and
IDirect3DDevice2 (test). An argument could be made to put such an
interop test into dlls/ddraw/tests/ddraw1.c, but this is not a priority
for me at the moment. d3drm.dll is the most likely "cause" of such a
mix. (A particularly interesting question is how
IDirect3DDevice2::{Get,Set}RenderState interacts with D3DOP_STATERENDER)

> Makes sense. So the handle is assigned to the interface, not the
> material itself?
That's how I understand the interface, and that's how we implement it.
Obviously you can write an explicit test for this in dlls/ddraw/tests :-) .

My understanding is that the handle refers to the IDirect3DMaterial
object. The D3DMATERIAL struct is stored inside that object. So if
change the D3DMATERIAL anything that stores a handle to the modified
IDirect3DMaterial will use the new colors.

If that were not the case you'd see IDirect3DMaterial::GetHandle return
a new handle after you call SetMaterial. It would also open a memory
management can of worms because the old material handle has to be kept
around somewhere together with the old color information.

> I can probaly do that later on once an application depends on this
> behavior. Handling this case right now would require me to keep two
> separate implementations. But if you feel that it's important to handle
> this, I don't mind keeping them separate.
Well, your test kinda relies on it, but as we've noticed succeeds for
some reason we don't understand :-) .

You can also try to create a d3drm device that doesn't have a depth
buffer at creation and look at the return value of
Viewport2::Clear(D3DRMCLEAR_ZBUFFER). I would expect an error.

My guess is that Viewport1::Clear shouldn't unconditionally use
D3DRMCLEAR_ALL, but instead check if a Z surface is available. If yes,
it uses D3DRMCLEAR_ALL, otherwise it uses TARGET | DIRTYRECTS. (It might
not use DIRTYRECTS - we don't really know what it does.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160807/55c2e389/attachment-0001.sig>