Hi, Design-wise I think the 8 triangles and readback grid make the test fairly difficult to read. You could set up a structure that contains the d3d parameters you're changing between the tests and the expected color and then loop over the table. Something like this:
const struct { BOOL d3drs_lighting; DWORD dp_flags; <- for things like D3DP_DONOTLIGHT DWORD fvf; void *vertices; DWORD expected_color; } test_data[] = { ... }; You can also think about sharing this control table between d3d2, d3d3 and d3d7 by having different color fields for that, but I don't know how well this will work. On Monday 07 November 2011 23:27:13 Octavian Voicu wrote: > + DWORD expected[] = { GRAY, WHITE, YELLOW2, YELLOW, GREEN, GREEN, BLUE, BLUE }; Please make data const where you can. > + /* Note: IDirect3DDevice3::DrawPrimitive calls with D3DVT_ vertex > types should fail. */ + > + /* Triangle 0 -- D3DFVF_VERTEX (vertices with normals, but without > colors). */ + hr = IDirect3DDevice3_DrawPrimitive(Direct3DDevice3, > D3DPT_TRIANGLELIST, D3DVT_VERTEX, > + vertices, 3, D3DDP_WAIT); > + ok(hr != DDERR_INVALIDPARAMS, "DrawPrimitive returned: %08x\n", > hr); I don't think there's a point in testing this, both D3DVT_* and D3DFVF_* are defines / enums that map to integers, and it is obvious that you get wrong behavior if you mix those. The ok condition looks strange. If you're trying to avoid a todo_wine, don't do that, just mark tests that show a difference between Wine and Windows as todo_wine. (I guess Wine currently returns DD_OK, and Windows returns D3DERR_INVALIDVERTEXFORMAT) > + /* Make sure getPixelColor works correctly. */ > + color = getPixelColor(device, 320, 240); > + ok(color == RED, "getPixelColor returned: %08x\n", color); We have some sanity checks for that in the main function Most of this applies to the d3d2 and d3d3 tests as well. I haven't looked over the cleanup patches yet.
signature.asc
Description: This is a digitally signed message part.