On 7 July 2010 12:32, Bjørnar Hansen <[email protected]> wrote: > On Tue, Jul 6, 2010 at 23:00, Henri Verbeet <[email protected]> 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.
