[10/11] ddraw/tests: Add assorted D3D3 DrawPrimitive/visual tests.
octavian.voicu at gmail.com
Tue Nov 8 05:08:21 CST 2011
On Tue, Nov 8, 2011 at 12:18 PM, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> On Tuesday 08 November 2011 01:14:22 Octavian Voicu wrote:
>> The idea behind using triangles was to fit everything in one screen so
>> I could debug it visually very easily. I'm thinking I can still have
>> that if I draw full-screen quads in a loop, like you suggest, then
>> blit one small rectangle to the primary surface, in different
>> positions for each test.
> I don't think that's necessary, I found those one-quad screens easier to debug
> than multi-quads, although that may be a matter of taste.
It gets a bit harder when you have more than a couple of tests,
because you have to follow the sequence of flashes, but the message
from the failures should be descriptive enough.
>> I think
>> we should cover special error cases if there are any (that is, if
>> D3DERR_INVALIDVERTEXTYPE is not returned for D3DVT_ constants).
> Well, you can't test them. D3DVT_LVERTEX is 2, and D3DFVF_XYZ is 2. The number
> 2 doesn't have any tags attached, so what you'd be testing is how
> drawPrimitive responds to D3DFVF_RESERVED0, not what it does with D3DVT_*
> The statement in the SDK doesn't make sense with that in mind.
I thought D3DVT_ values interpreted as FVFs didn't make sense. It
seems Windows accepts those values and returns D3D_OK, so I'll drop
> > About the ddraw/visual tests: I think we need one structure for each
>> of d3d, d3d2, d3d3, d3d7, where to have most of the things we store
>> globally or in local vars now, and make the create/release functions
>> work with that.
> Yes, I was about to write something like that as a response to the cleanup
Is it OK to leave them like this for now? That kind of refactoring is
going to make this patch series endless.
More information about the wine-devel