ddraw:d3d tests failing consistently

Francois Gouget fgouget at free.fr
Sat Oct 27 14:07:59 CDT 2007


On Sat, 27 Oct 2007, Stefan Dösinger wrote:
[...]
> If you look at various game boxes in the software shop next to you, you will 
> very often find notes like "Works on ATI radeon and Nvidia geforce cards. 
> Mobile versions of the cards are unsupported". Means, that if you have a 
> Destop radeon or gf card, you're lucky. If you have a mobile radeon or gf 
> card, and the game doesn't work, your problem. If you have an Intel card, 
> don't even try to start the game.

If the game fails on Windows, users will either blame the game maker or 
Intel. We don't care. However if it fails in Wine, the user will blame 
Wine, not Intel, and not the game maker.


[...]
> > I don't think the caps will really be useful here, but we could
> > retrieve the card and driver name, and skip the test for some
> > combinations. IDirect3D9::GetAdapterIdentifier() for example should
> > return enough information for d3d9. I'm not sure we want to go there
> > though, Alexandre has said before that the tests should simply fail on
> > broken setups.

Was he talking about broken Windows setups or broken Linux setups?
It's find to ignore clearly broken Linux setups (e.g. known buggy driver 
version), but calling every Windows system that does not give the result 
we want 'broken' is refusing to face reality.

When FindExecutable() returns success on NT4 instead of returning an 
error like it should, we don't say that NT4 is broken and that thus it's 
ok to let the test fail and that it is its job to fail. We don't do that 
because the test's job is not to detect bugs in Windows, but to document 
what the different versions of Windows do, and to make sure that Wine 
does the same as one of them. So we adjust the test to accept both 
results as valid so it succeeds on both systems.

I don't see why it should be different for the DirectX tests.


> Yes, that will work to filter out vmware, but I don't think we should do that. 
> The test just does its job when it fails on broken drivers.

Its job is to needlessly pollute the results?

Again, the test's job is not to detect broken systems, but to document 
the Windows behavior.


It seems what you want is unit tests that would garantee that WineD3D 
behaves in the way which _you_ have decided. Most of the time that's the 
same as writing a _conformance_ test, but apparently in this specific 
case it's different. If that's so, then maybe we have to see how we can 
distinguish the two (separate test suites, enabling additional tests 
when running in Wine, etc).

This sort of infrastructure could also be useful in the case I 
mentionned above, where a specific version of Windows returns something 
stupid, but where we'd very much prefer to match the behavior of the 
other non-buggy versions.


-- 
Francois Gouget <fgouget at free.fr>              http://fgouget.free.fr/
          tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY


More information about the wine-devel mailing list