Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things?
I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens.
I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt.
Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel..
Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself.
Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there.
If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems.
If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16..
Tom
Tom Spear <speeddymon <at> gmail.com> writes:
Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there.
If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems.
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. Currently 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 meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE.
To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() 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.
- Aric
-
Aric Cyr -
Tom Spear