https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #7 from Paul Gofman gofmanp@gmail.com --- (In reply to BabylonAS from comment #5)
Created attachment 64732 [details] wine output after editing registry (same WINEDEBUG)
Didn’t help. I suppose it’s time to try the other course of investigation, the one that isn’t about DirectX implementation.
No need to. Thanks for the additional logs & information. Your log confirms Comment #1 with a bit of additional details. This is from your log: --- 0009:trace:d3d:wined3d_adapter_init_limits Max anisotropy: 16. Mesa 18.3.6 implementation error: Invalid GLSL version in shading_language_version() Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa 0009:trace:d3d:wined3d_adapter_init_gl_caps GLSL version string: (null). ---
The next line of code after printing the message with NULL GLSL version string is: --- TRACE("GLSL version string: %s.\n", debugstr_a(str));
/* The format of the GLSL version string is "major.minor[.release] [vendor info]". */ sscanf(str, "%u.%u", &major, &minor); ----
It crashes in sscanf() with NULL string received for GLSL version string.
While that's probably worth fixing in terms of returning error instead of crashing here, unfortunately this won't let the application to run, wined3d is unlikely willing to workaround such a problem of getting NULL GLSL version string. Besides, the NULL string and inability to initialize shaders in GL driver size is likely not the only problem with it on the way.
This is not a Wine bug, the only way to fix it is to fix host OpenGL driver (maybe install some other one / version, or fix on the Mesa side). If you want to test it further from the Wine side and is ready to build Wine from source I can probably make a workaround patch tomorrow which will allow wined3d continue with GLSL disabled if GLSL version string is NULL. There is a small chance that after that you will be able to run the game with GLSL shaders disabled.