ddraw:d3d tests failing consistently
Stefan Dösinger
stefan at codeweavers.com
Sat Oct 27 15:09:17 CDT 2007
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
More information about the wine-devel
mailing list