ddraw:d3d tests failing consistently

[Stefan Dösinger]

Am Samstag, 27. Oktober 2007 21:07:59 schrieb Francois Gouget:
> 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.
Yes, that is the point.

> 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.
On the Linux side we're trying to abort running the tests as good as possible. 
I.e., if we detect a broken driver we disable features about which we know 
that they cause problems like X server crashes.

> > 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).
I want to document the behavior real world apps expect, and the freedom d3d 
implementations have is very, very limited. Games are usually pushed out 
without any QA work, most vendors do not even bother to run their games with 
the reference rasterizer or the debug runtime. Many game failures in Wine can 
be reproduced on Windows by changing some usually harmless settings. Use the 
refrast, or the debug runtime, and everything's broken. I just had such a 
case(bug 9774), other examples include Battlefield 1942 and Rollcage.

Windows apps are crappy software, Direct3D games are even worse.

> 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.
This would indeed be useful. It would allow to mark a test failure with 
something softer than a total failure, something like warn(). We could then 
warn if we detect a known Linux driver bug or a Windows driver behavior that 
is different from what games expect.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20071027/9e8e8b6b/attachment.pgp