d3d9/tests: Add test for surface format conversion

[Henri Verbeet]

On 7 July 2010 12:32, Bjørnar Hansen <tilbjornar at gmail.com> wrote:
> On Tue, Jul 6, 2010 at 23:00, Henri Verbeet <hverbeet at gmail.com> wrote:
>> Depends. What are you trying to prove / find out with this test?
>>
> I started out by testing the Frameranger demo in Wine. A fixme printed
> was that conversion from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8 was
> unimplemented, so I implemented that. Then I tested it successfully
> both on Wine and Windows.
>
In that case you probably mostly care about the correctness of that
specific conversion, if supported. This implies (partially)
implementing IWineD3DImpl_CheckDeviceFormatConversion() in wined3d. At
the very least you'll probably need to check if the formats themselves
are available, not all cards support floating point formats for
example.

> Right now I am a little confused, as the Microsoft reference does not
> mention conversion from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8.
>
MSDN is often wrong or misleading, in this case I think the limitation
on the formats may only apply to backbuffer -> display format
conversion (i.e. Present()), and perhaps not so much to StretchRect().
It's also possible for drivers to simply violate the spec.

> Also, to fix the Frameranger demo: Would it be better to make it avoid
> software blitting entirely?
>
If possible, sure. Probably the only case where we actually want to
blit on the CPU is if both surfaces are in system memory.