MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

[Mike Hearn]

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