RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
Roderick Colenbrander
thunderbird2k at gmail.com
Wed Nov 25 03:37:36 CST 2009
On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt <celticht32 at yahoo.com> wrote:
> Roderick Colenbrander wrote:
>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32 at 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
More information about the wine-devel
mailing list