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_ vertextypes should fail. */ +
/* Triangle 0 -- D3DFVF_VERTEX (vertices with normals, but withoutcolors). */ + 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.