On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celtich...@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