https://bugs.winehq.org/show_bug.cgi?id=53629
Bug ID: 53629 Summary: mixed gdi/dx9 rendering leads to a failure to render Product: Wine Version: 7.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
The summary is a guess and probably a wrong one.
wine version is set to 7.15, but it was first observed around 7th Oct 2020.
Anyway, in two games of a single dev (not really an engine, unless in the home-cooked sense) the games start, show a standard window then fail to render anything more. Mouse cursor still disappears upon entering the window and reappears upon leaving.
One is steamid 1289960, other currently pending (there are demos available for the original, non-steam versions).
Initially I thought it was something like the Diablo problem, even though ddraw isn't involved, yet there was something about child windows in 'win' channel.
Then I've ran apitrace.
After first Present call, a Reset call is made repeatedly and each time it fails.
Also of note is the fact that a native d3dx9_31 is required, otherwise a crash with something looking like a stack corruption ('Unhandled page fault on read access to CCCCCCCC at address ...') happens immediately.
Potentially of note: the hack makes things work with gl renderer, vulkan is still broken, though that might be due to the child window bug; gdi renderer makes things crash immediately with or without the hack.
If reset_enum_callback (in dlls/d3d9/device.c) is made to return D3D_OK in both Texture and Surface step, things seem to work correctly, but that looks like a leak-inducing step.
In vulkan case, console is flooded with repeated:
<threadid>:err:d3d:adapter_vk_draw_primitive Failed to apply draw state. <threadid>:err:d3d:wined3d_context_vk_apply_draw_state Failed to get graphics pipeline.
https://bugs.winehq.org/show_bug.cgi?id=53629
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- On further examination it seems the need for native d3dx9_31 is due to vkd3d-shader being utter crap at parsing the shaders (pretty basic vs_3_0/ps_3_0 stuff).
Upon failure to parse a NULL is returned (well, most likely one of shader's return parameters is set to NULL) and the game is unable to deal with that.
I wonder if some of resources not being released are like that due to being bound to shaders and those in d3d9_device_Reset should be left alone.