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.)