ddraw:d3d tests failing consistently

[Stefan Dösinger]

Am Samstag, 27. Oktober 2007 06:42:31 schrieb H. Verbeet:
> On 26/10/2007, Francois Gouget <fgouget at free.fr> wrote:
> > Parallels is a bit of a special case because it does not just replace
> > the graphics driver, but the DirectX dlls altogether. However VMware 5.5
> > does not do that.

> > That's precisely the problem. I would add, what about Neomagic chips
> > then? By your reasonning there's only Windows on Nvidia and Windows on
> > ATI, and maybe not even the latter.
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.

One of those games was the Settlers 2 remake. It just crashed on a friend's 
laptop with an Intel chip. I put a Win32 build of WineD3D into the game's 
directory, and see, it runs(slow, but perfectly playable). What did WineD3D 
fix? Definitly not the client d3d9 lib, it is the same on all Windows boxes. 
It was the driver part that broke the game.

So the Nvidia / ATI specific behavior *is* an issue for us. I just ran the 
d3d9 tests on my mother's laptop with an Intel card, and many tests failed. 
Many failures remind me of the behavior of WineD3D before it was fixed to fix 
some game(e.g. cubemap address modes, vertex shader fog). Other failures look 
quite severe too: Offscreen rendering fails, the z test fails in a really odd 
way(trying to make a screenshot). The mouse pointer leaves a visible mark on 
the screen. It seems that even vmware does better.

> WineD3D is in a bit of a special position there, because it actually
> does replace both the Direct3D dlls and the driver. While of course it
> shouldn't test the behaviour of a specific version of drivers from a
> specific vendor, it *should* at least for a part test the behaviour of
> a driver that behaves according to the specs.
All in all only the visual tests test the behavior of the driver, the others 
are focusing on the client library.

> > Anyway... Can this be fixed by better checking the Direct3D
> > capabilities? Does the test check for some undocumented feature or a
> > documented one? Do we know that it works with the Nvidia, ATI and Intel
> > drivers? If not, then maybe it should be removed?
>
> 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.
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.
-------------- 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/e7e77f84/attachment-0001.pgp