d3d9/tests: Add test for surface format conversion

Henri Verbeet hverbeet at gmail.com
Wed Jul 7 05:54:55 CDT 2010

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

> 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.

More information about the wine-devel mailing list