On 7 July 2010 12:32, Bjørnar Hansen tilbjornar@gmail.com wrote:
On Tue, Jul 6, 2010 at 23:00, Henri Verbeet hverbeet@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.