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

[chris ahrendt]

Roderick Colenbrander wrote:
> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> 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

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

[Roderick Colenbrander]

On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt <celticht32(a)yahoo.com> wrote:
> Roderick Colenbrander wrote:
> > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> 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