New subject: [PATCH 3/4] d3d9/tests: Add a test for signed formats.

3 Mar 2015

      2015-03-02 22:29 GMT+01:00 Stefan Dösinger stefan@codeweavers.com:
...

/* The input data was designed for D3DFMT_L6V5U5 and then transfered
* to the other formats because L6V5U5 is the lowest precision format.

* It tests the extreme values -1.0 (-16) and 1.0 (15) for U/V and

* 0.0 (0) and 1.0 (63) for L, the neutral point 0 as well as -1 and 1.

* Some other intermediate values are tested too. For the 8 bit formats

* the equivalents of -1 and 1 are -8 and 8, that's why there is no

* 0xffff input for these formats. The input value -15 (min + 1) is

* tested as well. Unlike what OpenGL 4.4 says in section 2.3.4.1, this

* value does not represent -1.0. For 8 bit singed data -127 is tested

* in the Q channel of D3DFMT_Q8W8V8U8. Here d3d seems to follow the

* rules from the GL spec. AMD's r200 is broken though and returns a

* value < -1.0 for -128. The difference between using -127 or -128 as

* the lowest possible value gets lost in the slop of 1 though. */

For the 8-bit format you mean that 1 is not representable in the
signed u/v components, correct?
Also "singed" typo, but otherwise good to me.
...

static const USHORT content_v8u8[4][4] =
{
   {0x0000, 0x7f7f, 0x8880, 0x0000},

   {0x0080, 0x8000, 0x7f00, 0x007f},

   {0x193b, 0xe8c8, 0x0808, 0xf8f8},

   {0x4444, 0xc0c0, 0xa066, 0x22e0},

};
static const DWORD content_v16u16[4][4] =
{
   {0x00000000, 0x7fff7fff, 0x88008000, 0x00000000},

   {0x00008000, 0x80000000, 0x7fff0000, 0x00007fff},

   {0x19993bbb, 0xe800c800, 0x08880888, 0xf800f800},

   {0x44444444, 0xc000c000, 0xa0006666, 0x2222e000},

};
static const DWORD content_q8w8v8u8[4][4] =
{
   {0x00000000, 0xff7f7f7f, 0x7f008880, 0x817f0000},

   {0x10000080, 0x20008000, 0x30007f00, 0x4000007f},

   {0x5020193b, 0x6028e8c8, 0x70020808, 0x807ff8f8},

   {0x90414444, 0xa000c0c0, 0x8261a066, 0x834922e0},

};
static const DWORD content_x8l8v8u8[4][4] =
{
   {0x00000000, 0x00ff7f7f, 0x00008880, 0x00ff0000},

   {0x00000080, 0x00008000, 0x00007f00, 0x0000007f},

   {0x0041193b, 0x0051e8c8, 0x00040808, 0x00fff8f8},

   {0x00824444, 0x0000c0c0, 0x00c2a066, 0x009222e0},

};
/* D3DFMT_L6V5U5 has poor precision on some GPUs. On a GeForce 7 the highest U and V value (15)
* results in the output color 0xfb, which is 4 steps away from the correct value 0xff. It is

* not the ~0xf0 you'd get if you blindly left-shifted the 5 bit values to form an 8 bit value

* though.

*

* There may also be an off-by-one bug involved: The value -7 should result in the output 0x47,

* but ends up as 0x4d. Likewise, -3 becomes 0x6e instead of 0x67. Those values are close to

* the proper results of -6 and -2. */

static const USHORT content_l6v5u5[4][4] =
{
   {0x0000, 0xfdef, 0x0230, 0xfc00},

   {0x0010, 0x0200, 0x01e0, 0x000f},

   {0x4067, 0x53b9, 0x0421, 0xffff}, /* 0x4067, 0x53b9, 0x0421, 0xffff */

   {0x8108, 0x0318, 0xc28c, 0x909c}, /* 0x8108, 0x0318, 0xc28c, 0x909c */

};

What did you mean to put in the comments here? Those currently there
match the actual content of the array.
...

       for (y = 0; y < 4; y++)

       {

           for (x = 0; x < tests[j].width; x++)

           {

               expected_color = expected_colors[y][x];

               if (!formats[i].blue)

                   expected_color |= 0x000000ff;

This is clearly my brain failing right now, but why is blue expected
to be 0xff when the texture component is missing?
...

       hr = IDirect3DTexture9_GetSurfaceLevel(texture, 0, &dst_surface);

       ok(SUCCEEDED(hr), "Failed to get surface, hr %#x.\n", hr);

       IDirect3DTexture9_GetSurfaceLevel(texture_sysmem, 0, &src_surface);

       ok(SUCCEEDED(hr), "Failed to get surface, hr %#x.\n", hr);

       hr = IDirect3DDevice9_UpdateSurface(device, src_surface,

               &tests[j].src_rect, dst_surface, &tests[j].dst_point);

       ok(SUCCEEDED(hr), "Failed to update surface, hr %#x.\n", hr);

       IDirect3DSurface9_Release(dst_surface);

       IDirect3DSurface9_Release(src_surface);

       hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0x00003300, 0.0f, 0);

       ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr);

       hr = IDirect3DDevice9_BeginScene(device);

       ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr);

       hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, &quad[0], sizeof(*quad));

       ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr);

       hr = IDirect3DDevice9_EndScene(device);

       ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr);

       for (y = 0; y < 4; y++)

       {

           for (x = 0; x < tests[j].width; x++)

           {

               if (tests[j].width == 4)

                   expected_color = expected_colors2[y][x];

               else

                   expected_color = expected_colors3[y];

               if (!formats[i].blue)

                   expected_color |= 0x000000ff;

               color = getPixelColor(device, 80 + 160 * x, 60 + 120 * y);

               ok(color_match(color, expected_color, 1)

                       || color_match(color, expected_color, formats[i].slop_broken),

                       "Expected color 0x%08x, got 0x%08x, format %s, location %ux%u.\n",

                       expected_color, color, formats[i].name, x, y);

           }

       }

Cool additional test for UpdateSurface, thank you for that.
Here and in the previous test I guess you might want to put the
slop_broken check into a broken(), unless that also fails on Linux.

Re: [PATCH 3/4] d3d9/tests: Add a test for signed formats.