Re: [PATCH 4/5] ddraw: Add depth clamp tests.

[Paul Vriens]

On 01/26/2010 06:31 PM, Henri Verbeet wrote:
> - color = getPixelColor(device, 150, 150);
> - todo_wine ok(color_match(color, 0x00ffffff, 1), "color 0x%08x.\n", color);

Hi Henri,

This particular test fails on some VMware and VirtualBox boxes. We've 
been through this before about whether broken() is appropriate or not.

The attached patch adds an explicit broken color value instead of some 
color_match().

Not sure what's the best way though.

We don't have many test runs on real Windows for these new tests so I 
can't be a 100% sure if it's just VMware/VirtualBox. Some real boxes 
have run the ddraw:visual tests but not these new ones as they bailed 
out because of other issues.

Any thoughts on this one?

[PATCH 4/5] ddraw: Add depth clamp tests.

[Henri Verbeet]

Paul Vriens wrote:
> On 01/26/2010 06:31 PM, Henri Verbeet wrote:
> > - color = getPixelColor(device, 150, 150);
> > - todo_wine ok(color_match(color, 0x00ffffff, 1), "color
> >
> > 0x%08x.\n", color);
>
> Hi Henri,
>
> This particular test fails on some VMware and VirtualBox boxes. We've
> been through this before about whether broken() is appropriate or not.
>
> The attached patch adds an explicit broken color value instead of some
> color_match().
>
> Not sure what's the best way though.
>
> We don't have many test runs on real Windows for these new tests so I
> can't be a 100% sure if it's just VMware/VirtualBox. Some real boxes
> have run the ddraw:visual tests but not these new ones as they bailed
> out because of other issues.
>
> Any thoughts on this one?

It does look broken, since "quad6" should have been clipped. I see the
same behaviour when using the reference device, but the test works as
expected with the "RGB Device". Of course that introduces other test
failures instead. I'd expect the refrast to behave correctly, but going
by some of the skips, that's perhaps too optimistic.

Henri