Hi ho,
Every so often I try out my favourite game to see how well it runs in Wine. This time, I found the demo (I have the full game but the demo is easier to debug) was working well!
The following snowboarding game:
http://www.housemarque.com/games/supremesb/ssb_demo.exe
is not only a lot of fun but also Very Nearly There in Wine. There are only two problems preventing it from running perfectly:
1) There seems to be a bug in our msvcrt file reading APIs. I've chased this one before and got nowhere, but maybe somebody more familiar with the code can find it. We seem to pass back corrupt data: with builtin msvcrt the demo complains with a nicely detailed assertion that it can't find a file marker it's looking for. Native MSVCRT from WinXP makes it work (once you set winver=winxp)
2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's showing the pre-recorded demos the sky is just fine. The rest of the graphics are perfect.
Finally if you put it in desktop mode, an X protocol error occurs initialising OpenGL. The XGetWindowAttributes call complains of a bad window. I debugged this for a bit and got nowhere, it wasn't as straightforward as it looked. Suffice to say that at the point it died opengl32.dll had been initialised several times already with the same value for root_window, and it worked each time previously (yes sync was enabled).
I think this definitely used to work, so it feels like some WM rewrite regression to me. I could well be wrong though.
This seems to affect all OpenGL+desktop mode apps.
To make the game let you choose OpenGL in the setup program it has to be run in win2k/winxp mode. I do not know why.
If you get it going, see if you can beat my best time (when playing on Linux) of 2:02. Have fun! :)
thanks -mike
- There seems to be a bug in our msvcrt file reading APIs. I've chased this one before and got nowhere, but maybe somebody more familiar with the code can find it. We seem to pass back corrupt data: with builtin msvcrt the demo complains with a nicely detailed assertion that it can't find a file marker it's looking for. Native MSVCRT from WinXP makes it work (once you set winver=winxp)
Yeah, I already tried once to debug this and was a bit stuck... I had no idea how to progress further on this though.
- When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's showing the pre-recorded demos the sky is just fine. The rest of the graphics are perfect.
Did you try with a 'reference driver' (like Mesa) ? It's pretty rare that a bug is specifically in Wine's implementation of OpenGL but rather in interactions between Wine and the GL driver.
And more important, it's a bitch to find out exactly which graphic primitives are responsible to display something like the sky in thousands of GL traces so it's almost impossible to debug.
Finally if you put it in desktop mode, an X protocol error occurs initialising OpenGL. The XGetWindowAttributes call complains of a bad window. I debugged this for a bit and got nowhere, it wasn't as straightforward as it looked. Suffice to say that at the point it died opengl32.dll had been initialised several times already with the same value for root_window, and it worked each time previously (yes sync was enabled).
The bug was actually not that hard to find. Basically, what happens is the following (with some additionnal TRACEing added in X11DRV):
0009:trace:x11drv:X11DRV_create_desktop created 4800007 'Supreme.exe' starts and gets its own Desktop window 000c:trace:x11drv:X11DRV_create_desktop created 4e00007 Now the 'graphic chooser' application starts and creates its own Desktop window 000c:trace:opengl:process_attach 0x78052988 04e00007 000c:trace:opengl:process_attach 0x78052988 04e00007 (...) In the case of the 'graphic chooser', one can see it uses the correct window. 0009:trace:opengl:process_attach 0x78054910 04e00007 But then the main games does a 'LoadLibrary' on OpenGL and the 'process_attach' function is called.
And as one can see, the Desktop window 'atom' seems to have been changed by the 'graphic chooser' application which means that 'Supreme.exe' tries to get the Window attributes of a window that is now deleted => nice X11 crash.
This will surely be fixed by any proper 'only one window' Desktop patches (for which I lust for since a long time :-) )... I will see how I could 'hack' this while waiting for the proper Desktop fix (maybe having some 'process-local' atom to store the Desktop window instead of a global one).
This seems to affect all OpenGL+desktop mode apps.
It only affects applications which do start 'helper' applications before doing OpenGL stuff. For example, 'TreeMark' works fine in Desktop mode.
Lionel PS: are the 'TID' globally unique or are they only 'process unique' ?
On Thu, 2004-12-23 at 13:53 +0100, Lionel Ulmer wrote:
Yeah, I already tried once to debug this and was a bit stuck... I had no idea how to progress further on this though.
I sunk quite a few hours into it and didn't see anything. I think the only way to find this one will be by writing lots of unit tests and hoping one trips.
Did you try with a 'reference driver' (like Mesa) ? It's pretty rare that a bug is specifically in Wine's implementation of OpenGL but rather in interactions between Wine and the GL driver.
Nope. I did think it may be a driver issue, I'm using the nVidia binary drivers (latest release). I will go back to "nv" which should force Wine to use Mesa, and see if it still happens.
And more important, it's a bitch to find out exactly which graphic primitives are responsible to display something like the sky in thousands of GL traces so it's almost impossible to debug.
Ah :( I was wondering how you did it, I thought there may be some magic tool or technique you had. I suppose not :(
And as one can see, the Desktop window 'atom' seems to have been changed by the 'graphic chooser' application which means that 'Supreme.exe' tries to get the Window attributes of a window that is now deleted => nice X11 crash.
Atoms set on the window should be process scoped not global. I think this is something for Alexandre to look at.
Maybe we need some unit tests for window atoms if we don't already have them.
It doesn't really matter for me. The game (for once) works perfectly in full screen mode. Now I have a launcher on my panel and desktop with the right icon, that launches the app in fullscreen mode, and runs (nearly) perfectly with native performance. That's how Wine should be! Merry Christmas everybody :D
thanks -mike
On Thu, Dec 23, 2004 at 01:14:17PM +0000, Mike Hearn wrote:
Atoms set on the window should be process scoped not global. I think this is something for Alexandre to look at.
Well, after some more additional TRACEs, it's not an atom problem after all... It's just that the HWND for the desktop window is the same for both processes (which is normal) but that means that the second process just overwrites the 'whole_window' atom for the 'common' desktop window and corrupts it for the first process started.
So I do not have an easy fix in mind except the merging of the various 'winedesktop' work that was done some time ago to have only one X11 window.
Lionel
Lionel Ulmer wrote:
On Thu, Dec 23, 2004 at 01:14:17PM +0000, Mike Hearn wrote:
Atoms set on the window should be process scoped not global. I think this is something for Alexandre to look at.
Well, after some more additional TRACEs, it's not an atom problem after all... It's just that the HWND for the desktop window is the same for both processes (which is normal) but that means that the second process just overwrites the 'whole_window' atom for the 'common' desktop window and corrupts it for the first process started.
So I do not have an easy fix in mind except the merging of the various 'winedesktop' work that was done some time ago to have only one X11 window.
What about just not using desktop mode?
Rob
On Thu, Dec 23, 2004 at 02:22:36PM +0000, Robert Shearman wrote:
What about just not using desktop mode?
Ah no, we won't re-start the Desktop mode flame-war :-)
Lionel
PS: and yes, as it works just fine in non-Desktop mode, it's not a 'severe' bug at all.
-
Lionel Ulmer -
Mike Hearn -
Robert Shearman