On 13 February 2014 14:52, Martin Storsjo martin@martin.st wrote:
- IDirect3DSurface9 *surface = NULL, *target = NULL;
You don't need those to be NULL.
- HRESULT color;
You'll want to use D3DCOLOR instead of HRESULT here.
/* Some (all?) Windows drivers do not support YUV 3D textures, only 2D surfaces in* StretchRect. Thus use StretchRect to draw the YUV surface onto the screen instead* of drawPrimitive. */if (IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0,D3DRTYPE_SURFACE, format) != D3D_OK){skip("%s is not supported.\n", fmt_string);continue;}
You should also verify the StretchRect() is supported with CheckDeviceFormatConversion().
BYTE Y = (color >> 16) & 0xff;BYTE U = (color >> 8) & 0xff;BYTE V = (color >> 0) & 0xff;
It's probably just as easy to just store the separate components to begin with.
hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT);ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr);/* Native D3D can't resist filtering the YUY surface, even though we asked it not to* do so above. To prevent running into precision problems, read at points with some* margin within the rect. */
That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.
On Fri, 14 Feb 2014, Henri Verbeet wrote:
On 13 February 2014 14:52, Martin Storsjo martin@martin.st wrote:
BYTE Y = (color >> 16) & 0xff;BYTE U = (color >> 8) & 0xff;BYTE V = (color >> 0) & 0xff;It's probably just as easy to just store the separate components to begin with.
Actually, since color can either be test_data[i].color1 or test_data[i].color2, splitting it per component would blow it up into Y1/Y2, U1/U2, V1/V2, and duplicating the condition for selecting color based on coordinate for all three components, so I think this format is simpler in the end.
hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT);ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr);/* Native D3D can't resist filtering the YUY surface, even though we asked it not to* do so above. To prevent running into precision problems, read at points with some* margin within the rect. */That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.
I tested that now as well, and there's no difference, the sharp edges in the YUV texture are blurred when scaled up.
I applied the other changes you suggested, those changes will be part of the next resend of the patchset.
// Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-17 12:53, schrieb Martin Storsjö:
On Fri, 14 Feb 2014, Henri Verbeet wrote:
That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.
I tested that now as well, and there's no difference, the sharp edges in the YUV texture are blurred when scaled up.
I applied the other changes you suggested, those changes will be part of the next resend of the patchset.
D3DTEXF_NONE behaves like D3DTEXF_POINT if used for minification or magnification. It only has a different behavior when assigned to D3DSAMP_MIPFILTER. There is no way to do no min/mag filtering when the source surface / texture size doesn't exactly match the destination rectangle size.
In my yuv_color_test cleanup patch I have reworded the comment to correctly say "point filtering" instead of "no filtering".
-
Henri Verbeet -
Martin Storsjö -
Stefan Dösinger