On Mon, Jul 5, 2010 at 21:37, Stefan Dösinger stefandoesinger@gmx.at wrote:
The DirectX9 SDK "Blobs" sample needs it. It creates a R32F surface, stretches to a R16F and then uses it for drawing. Later on I realized that DirectX9 cards(at least my GF7400) don't support R16F, so the sample uses the original R32F surface for rendering. DirectX10 cards support R16F however, it would be interesting to see how this sample reacts to that.
On a Windows XP machine with a ATI HD 4870 graphics card, D3DERR_INVALIDCALL was returned so I assumed it was an invalid call...
On Mon, Jul 5, 2010 at 21:23, Henri Verbeet hverbeet@gmail.com wrote:
You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to determine which conversions are supported.
Currently, that method always returns OK. Seems pointless to use it, but I've implemented it in my revised patch.
Looking at [1], should we test for all combinations of source/target formats?
The frameranger demo [2] triggers conversions from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8, which is, according to the Microsoft reference, not a valid conversion. I created a test for this, and it successfully executes on Windows XP. What's with that?
[1] http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/reference/... [2] http://www.pouet.net/prod.php?which=53647
On 6 July 2010 22:38, Bjørnar Hansen tilbjornar@gmail.com wrote:
On Mon, Jul 5, 2010 at 21:23, Henri Verbeet hverbeet@gmail.com wrote:
You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to determine which conversions are supported.
Currently, that method always returns OK. Seems pointless to use it, but I've implemented it in my revised patch.
Well yeah, it's essentially unimplemented, but that may even be the issue in some cases. The point is that you can't really depend on any conversion being available before checking for it first.
Looking at [1], should we test for all combinations of source/target formats?
Depends. What are you trying to prove / find out with this test?
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.
However, as Wine is in code freeze right now I decided to only send a patch with tests for the existing format conversions.
Right now I am a little confused, as the Microsoft reference does not mention conversion from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8.
Also, to fix the Frameranger demo: Would it be better to make it avoid software blitting entirely?
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.
-
Bjørnar Hansen -
Henri Verbeet