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.
signature.asc
Description: This is a digitally signed message part.