Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

[chris ahrendt]

Roderick Colenbrander wrote:
> On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt  wrote:
> > Roderick Colenbrander wrote:
> > > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt  wrote:
> > > > Ok going through and looking at the next failure in wine tests I found this one :
> > > >
> > > > If you look at the code its:
> > > >
> > > > 779     color = getPixelColor(device, 160, 120);
> > > >  780     red =   (color & 0x00ff0000) >> 16;
> > > >  781     green = (color & 0x0000ff00) >>  8;
> > > >  782     blue =  (color & 0x000000ff);
> > > >  783     ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff ,
> > > >  784        "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color);
> > > >
> > > > but in MSDN  it says :
> > > >
> > > > This value is a 32-bit value used to specify an RGB color or CLR_INVALID
> > > >
> > > > Format of the rgb color is :
> > > >
> > > > 0x00bbggrr
> > > >
> > > > The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and
> > > > the third byte contains a value for blue.
> > > >
> > > > The high-order byte must be zero.
> > > >
> > > > The maximum value for a single byte is 0xFF.
> > > >
> > > > so shouldn't it be something like this:
> > > >
> > > > red   = color & 0x000000FF;
> > > >    green = ( color & 0x0000FF00 ) >> 8;
> > > >    blue  = ( color & 0x00FF0000 ) >> 16;
> > > >
> > > > not the what is in the test? because of the following C action
> > > >
> > > > expression1 >> shift_value
> > > >
> > > > Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if
> > > > the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of
> > > > shift_value. If expression1 is signed, then the result is implementation specific.
> > > >
> > > > so the test seems to be assigning the wrong values to the RGB.... Correct?
> > > >
> > > > chris
> > >
> > > We are creating the framebuffer in the ARGB format (see init_d3d9).
> > > D3D supports a variety of formats and we don't use the gdi RGB macro.
> > >
> > > Roderick
> >
> > Ok... but apparently  this is returning it though in the above bbggrr format when color comes back  so how do you set it
> > to come back in the ARGB format??? Is that setup in the init_d3d9?
> >
> > chris
>
> The test passes properly on Wine + Nivida and I believe even on Intel.
> There are just some bugs in the ATI drivers. That's the case with most
> of the failing ddraw/d3d tests on ATI and other drivers.
>
> Roderick

Oh I realise that... thats why I am trying to figure out where so I can open a bug with ATI...

chris