-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-11 12:14, schrieb Martin Storsjo:
hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL);ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr);
Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code.
There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this.
memset(&lr, 0, sizeof(lr));hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0);ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr);
There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds.
switch (format){case D3DFMT_YV12: v_buf = chroma_buf; u_buf = chroma_buf + 4 * lr.Pitch/2; break;case D3DFMT_I420: u_buf = chroma_buf; v_buf = chroma_buf + 4 * lr.Pitch/2; break;default: break;}
The switch causes a warning here because YV12 and I420 are not part of the D3DFORMAT enum. Please use an if to make the compiler happy. Set v_buf and u_buf to NULL in case of other formats - this should avoid the warning that they may be uninitialized. (Although I think the compiler is broken here. It should see that they're not used for formats that are not YV12 and I420.)
/* Draw the top left quarter of the screen with color1, the rest with color2 */for (y = 0; y < 8; y++){for (x = 0; x < 8; x += 2){DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2;BYTE Y = (color >> 16) & 0xff;
It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on.
hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0);
No need to clear the Z buffer.
ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with 0x%08x\n", hr);
Please use %#x instead of 0x%08x and add interpunctuation at the end of the ok message. Another set of unwritten style rules :-\ .
On Wed, 12 Feb 2014, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-11 12:14, schrieb Martin Storsjo:
hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL);ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr);Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code.
Indeed, I changed the texture size later yesterday (and removed the hardcoded numbers by making the width/height a local variable); will check that capability.
There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this.
Yeah, it's probably not worth worrying about that case.
memset(&lr, 0, sizeof(lr));hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0);ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr);There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds.
Ok - this was an artifact from the existing yuv_color test FWIW.
/* Draw the top left quarter of the screen with color1, the rest with color2 */for (y = 0; y < 8; y++){for (x = 0; x < 8; x += 2){DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2;BYTE Y = (color >> 16) & 0xff;It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on.
I guess it would make things a little bit more difficult when the output is filtered. As long as we calculate how to hit the center of the pixels correctly I guess it should work, but I went the easy route and just draw the top-left quarter of the screen in one color and the rest in another, and sample at four points near the corners of each quadrant.
Handling the individual two different Y values in UYVY/YUY2 is already tested in the yuv_color test anyway, and for the other pixel formats there isn't really any distinction between first/second Y samples.
I'll fix up the other style issues you pointed out and resend the set later today then.
// Martin
-
Martin Storsjö -
Stefan Dösinger