search

doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
13.2k stars 851 forks source link

[d3d11] Sweet Transit (Steam game id 1612770) shows black screen only #2809

Closed gofman closed 2 years ago

gofman commented 2 years ago

It is black screen both with wined3d and dxvk, also reproducible on Windows with dxvk dropped in.

The issue here is that the game depends on proper validation in ID3D11Device::CreateInputLayout(). It passes wrong position semantic name and expect that to fail with proper error code, when it does it corrects itself. Otherwise it is left with the vertex shaders with unbound position input. This is coming from the engine the game is using which is actually available with the source code, here is the place of interest: https://github.com/MonoGame/MonoGame/blob/158c0154ac18ed6102c65e24665c6a080ccb8ed2/MonoGame.Framework/Platform/Graphics/Vertices/InputLayoutCache.cs#L97

I made a patch for Wine's d3d11 which has a test covering some details of the validation: https://gitlab.winehq.org/wine/wine/-/merge_requests/618

doitsujin commented 2 years ago

Not sure I understand what a mandatory shader input is, in general unbound inputs are defined to be zero, and input layouts are not required to provide any inputs at all. Why is SV_Position special as an input where it has no meaning at all?

gofman commented 2 years ago

SVPosition is special in a sense that it is treated the same way as any arbitrary semantic name, not as other SV names which are allowed to be unbound in CreateInputLayout(), as my test shows. And I am not saying that any input is not allowed to be unbound, that is specifically CreateInputLayout() which appears to have some validation.

doitsujin commented 2 years ago

I did some more digging, and it looks like SV_Position is not actually special, it's treated the same way as other VS outputs (SV_ClipDistance, SV_RenderTargetArrayIndex, etc). However, SV_InstanceID and SV_VertexID are special since they are built-in variables with an actual meaning and don't need to be defined by the input layout.

doitsujin commented 2 years ago

3edb0ef11405bf908efcde821d206a28b91901b8 should fix this, and based on my testing also behaves correctly when SV_VertexID and SV_InstanceID are defined by the input layout and the input layout is then used with a shader that uses a non-sysval semantic at the same location.

gofman commented 2 years ago

Yes, it fixes the game here and passes my tests.