https://bugs.winehq.org/show_bug.cgi?id=48788
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Created attachment 66705 --> https://bugs.winehq.org/attachment.cgi?id=66705 Hacks for builtin ddraw mode
I've tested the GOG version of the game.
This is not a recent regression.
First of all, GOG ships its own ddraw.dll for this game which probably fixes the game for the newer Windows versions. This ddraw.dll translates the ddraw API to d3d9. For that to work under Wine one needs to use 'native' ddraw override, that is, WINEDLLOVERRIDES="ddraw=n" or set such an override through winecfg for this Wine prefix. When the provided DLL is used the game does not crash, but the menu is drawn somewhat partially. This looks like something between the lines of bugs like Bug #2082, Bug #47036
The game not working with builtin ddraw.dll looks like an issue by itself though. The reason is not in _palette_set_entries like crash log could suggest. The application locks primary surface to update it, and eventually writes past end of the surface data occasionally overwriting wined3d palette structure which happens to go next (sometimes is crashes in the other place though). This part looks exactly like Bug #46803, even if it crashes in a different place (I was getting either crashes randomly). The attached hack ultimately increases the size of memory buffer allocated for texture and fixes the crash. It likely works on Windows by chance, though I did not exactly prove that it is not something caused by some sizes or positions returned slightly different under Wine.
With the crash worked around, the game displays black screen and again looks like something between the lines of Bug #2082, Bug #47036. The attached hack works around that partially, now the menu is partially displayed nearly the same way as with ddraw.dll provided by GOG.com.