[Bug 6190] New: regressions: Supreme Snowboarding fails since 0.9.19

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=6190

Summary: regressions: Supreme Snowboarding fails since 0.9.19
           Product: Wine
           Version: 0.9.20.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-binary
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Hi,

I've been testing Supreme Snowboarding 1.033 on Debian Ubuntu Breezy and Dapper.
While the following versions work, more recent ones now fail.

Works:
20050725 Breezy
0.9.9 Dapper
0.9.15 Breezy & Dapper
0.9.16 Breezy & Dapper

Fails:
0.9.19 Dapper
0.9.20 Dapper

I recommend using win2k mode, because the preferences requester then offers
OpenGL as rendering method (next to Software2, DirectX7 and DirectX6).
However, none of the bugs is related to OpenGL as I've also tested Software2
mode, with identical results.

There are possibly several bugs:
- Display_Config.exe may crash when selecting anything else than OpenGL
rendering. Or it does not crash, but it does not refresh its window correctly,
until OpenGL is choosen again.

- Running Supreme.exe initially works, however as soon as one enters the race or
training menu, both screen animation and sound become chopped up, while CPU goes
to 100%.  It is as out of every second, the machine stands still for half of it.
The snowboarder avatar is not rendered (Keith, Vincent etc.).  If continuing
from there, the game hangs as soon as one tries to enter the course (after
selecting snowboarder, board and whether). Luckily, wine reacts to Ctrl^C, a
window pops up and enables to terminate the program.

With 0.9.15/16 CPU% is at 80% while in the menus (anim and sound playing), and
100% during race.

To choose a rendering method without Display_Config.exe, edit:
Games\Supreme\rd_config.txt:
api_name	= "OpenGL";
width	= 800;
height	= 600;
depth	= 32;
card_id	= 0;
fullscreen	= 1;

o wine-0.9.19 produces the symptoms describe above.

o wine-0.9.20 behaves even worse than 0.9.19. It doesn't run at all and yields:
X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  17 (X_GLXVendorPrivateWithReply)
  Serial number of failed request:  384
  Current serial number in output stream:  384
I found a message where [e-mail] thinks it's an ATI bug.
http://bugs.winehq.org/show_bug.cgi?id=6098
However I have an Intel i810 on-board chip.

o wine-0.9.15/16 with DirectX7 rendering produce some incorrect results compared
with Software2 or OpenGL modes (DirectX6 is even worse).  That's a topic for a
different, future bug report (I'd prefer to report current behaviour with these
if the next 0.9.21 would work again).

I'm sorry I haven't attached any logfiles. I'll readily do so if you tell me
which of the many options to log with WINEDEBUG=... could help you.

After installing the game, I had to perform the steps in WININIT.INI manually:
[rename]
c:\windows\system32\Mfc42.dll=c:\windows\system32_Mfc42.dll
c:\windows\system32\Msvcp60.dll=c:\windows\system32_Msvcp60.dll
c:\windows\system32\ws2help.dll=c:\windows\system32_ws2help.dll
c:\windows\system32\Msvcrt.dll=c:\windows\system32_Msvcrt.dll
Of course, msvcrt.dll is being ignored (builtin default)

I'm quite surprised wine did not do that for me. Did I miss something?

o I offer to also test the missing versions 0.9.17-18 if this helps you. 
However the site where I usually download your distribution does not list these.
http://wine.budgetdedicated.com/apt/pool/main/w/wine/

To test some versions under both Breezy and Dapper, I made use of wine's ability
to locate its files itself.  I used dpkg --extract directory and set the WINExyz
variables.  So identical wine binaries where tested with both Breezy and Dapper
and always produced identical results.

Regards,
 Jörg Höhle