Aric.Cyr at gmail.com
Wed Dec 21 20:29:09 CST 2005
Tom Spear <speeddymon <at> gmail.com> writes:
> Aric Cyr wrote:
> >>>I took a look at the D3D_OK hack, and I believe the problem to be
> >>>CheckDeviceFormat in wined3d/directx.c. This function should return an
> >>>error if
> >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth.
> >>>it just returns OK for most formats though. This code is really just a
> >>>stub as
> >>>it stands, and needs to be converted to check if there are any visuals that
> >>>the requested format's requirements, and if there is, return D3D_OK,
> >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case
> >>>(you'll need to add it) in wined3d/directx.c in
> >>>and see if that fixes that issue or not. This would be just another hack
> >>>though, so a real patch would still be necessary as I decribed above.
> Well I took a stab at adding the case for D3DFMT_D32, to the bottom of
> the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed
> to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes
> the first one and then goes to do the second one, but crashes in a
> different spot, so it seems we also have some stack corrupion (as was
> mentioned in the bug).. So that hack works for now, I would suggest
> that since the rest of that code is stubbed out, we should probably go
> ahead and submit a patch so we can at least run the darn thing and then
> start debugging the stack corruption issue.
Thanks for testing this out. You have proved my theory correct, so I'll see
about making a patch which will correct CheckDeviceFormat(). Basically that
whole function needs a re-write, so I'd rather do it that way than to put this
hack in there. Especially since, I assume, this problem is not present on
nVidia systems, only ATI.
> I should add that on the first run, I disabled the title screens between
> benchmarks, and changed the "Display and CPU Settings" so that I was
> using 32-bit textures and triple buffering, and it ran thru several of
> the tests, while on the 2nd and 3rd runs, I left all settings at
> defaults; during run 2, it died just after the title screen for mark #2,
> and during run 3, it died in the middle of mark #2...
If I'm not mistaken, doesn't 3DMark change resolutions between benchmark and
title screens? If so, it is possible, and quite likely that there is a
resolution change bug in wine. If I recall, I had similar crashing problems
with World of Warcraft if I tried to change resolutions from in-game.
More information about the wine-devel