Closed xDShot closed 2 years ago
Do you mean, you're trying to use d3d8to9 on Linux? If yes, I don't see reasons why d3d8to9 should be compatible with Linux. It's designed to work with DirectX API, which is not open source. The open-source Linux tools, like Wine attempt to reproduce the behaviour of Windows functions, but they're never 100% the same, and smaller or bigger issues may occur. I also don't think d3d8to9 would fix any compatibility issues on a different OS than Windows.
'd still love to have benefits from d3d9 like reshade, vulkan translation, etc. There's also a bug with d3d8 rendering with reduced color depth, causing noticeable gradient artefacts.
I understand, but logically thinking, if it works fine on Windows, but has issues with Wine / proton (I'm not familiar with these things), then the problem lays in these "replicators", not d3d8to9 itself. There is also a huge chance that fixes to d3d8 have been applied directly by these "replicators", so d3d8to9 conflicts with some changes.
I understand, but logically thinking, if it works fine on Windows, but has issues with Wine / proton (I'm not familiar with these things), then the problem lays in these "replicators", not d3d8to9 itself. There is also a huge chance that fixes to d3d8 have been applied directly by these "replicators", so d3d8to9 conflicts with some changes.
I'd say you know about linux gaming little to none.
Waiting for @crosire response
I'd say you know about linux gaming little to none.
Waiting for @crosire response
Since you know so much more, and the issue is already open, maybe you'd like to explain why do you think that d3d8to9 is responsible for this issue, and not the different libraries on Linux? I'm pretty sure crosire would appreciate if you attached the d3d8.log as well.
why do you think that d3d8to9 is responsible for this issue, and not the different libraries on Linux
I tried with both dxvk and stock wined3d with different proton revisions with same symptoms. There might be other causes, but for now i stick to blaming d3d8to9.
Will see if there's log file when get to pc although i can't recall it appeared in the game directory.
None d3d8.log appear
After some investigations I found something. When I add -skipstartup -nodialog
, load bar comes to end and this error appears:
Please try to compile d3d8to9, without the D3D8TO9NOLOG
Preprocessor Definition.
Then it should create the d3d8.log
file in the same directory as the game executable / DLL.
If you're unable to compile it yourself, you can use this version: https://we.tl/t-DK3PDviYTI I has dynamic and static runtime library versions inside the zip archive.
https://www.vogons.org/viewtopic.php?t=51579 maybe installing this would help?
Please try to compile d3d8to9, without the
D3D8TO9NOLOG
Preprocessor Definition. Then it should create thed3d8.log
file in the same directory as the game executable / DLL.If you're unable to compile it yourself, you can use this version: https://we.tl/t-DK3PDviYTI I has dynamic and static runtime library versions inside the zip archive.
Same symptoms with both libs, no log file
https://www.vogons.org/viewtopic.php?t=51579 maybe installing this would help?
Didn't help unfortunately
UPD: it actually did produce log, just in unexpected place - inside e2driver dir
Progress:
Switched to https://github.com/GloriousEggroll/proton-ge-custom. It loads to main menu, but after starting new game appears this:
and different log
Line 23: Unexpected input *
Line 25: Unexpected input *
add r5.xyz, r5, *v1
and:
mad r0.xyz, *r2, v0, r0
So this version of proton does not "understand" the asterix symbols in the NewSourceCode
. I honestly still think this issue is not d3d8to9 related. Even if this could be somehow workarounded, the problem lays on the higher level than this wrapper.
If you have time, you can try playing with the source code around this place: https://github.com/crosire/d3d8to9/blob/main/source/d3d8to9_device.cpp#L1810
Maybe proton expects the &
character to be used instead of *
. Can be only guessing.
I would recommend to try running this game using the pure Wine (or wine staging), with d3dx9_43.dll library installed.
With d3d8to9 and WINE always use original so called native d3dx9_43.dll and d3dcompiler_43.dll libraries!!! Because WINE's implementation of these have bugs, particulary compiler... It goes like this:
WINEDLLOVERRIDES="d3d9=n;d3d8=n;d3dx9_43=n;d3dcompiler_43=n" wine MaxPayne2.exe
This force everything to native or crash if needed but missing, so d3d9 (this is for example dxvk (d3d9 to vulkan) or nine (native mesa/gallium d3d9), or if wined3d (d3d9 to opengl) is used then revert n to b so builtin), d3d8 is d3d8to9 and else are original libraries to force be used... all this because wine libs have bugs... and it is not just these, but for d3d8to9 that is. And for EAX effects replace dsound with dsoal one and configure it... but that is a different story and unrelated bonus suggestion here :D
And forgot about that widescreen fix, not sure if used. As i see that is named d3d8.dll, so maybe that could be a problem too. Well, rename that widescren d3d8.dll to winmm.dll and allow d3d8to9 to be used in global.ini file... so entire pleasure should look like this:
WINEDLLOVERRIDES="d3d8=n;d3d9=n;d3dx9_43=n;d3dcompiler_43=n;dsound=n;winmm=n,b" wine MaxPayne2.exe
With that you have d3d8to9 translating to d3d9 of choice (3 choices, whatever works for you there), forced native libraries because of wine bug, eax fix and widescreen fix.
That worked! With d3dx9_43 and d3dcompiler_43 installed from protontricks the whole setup now works! Thanks everyone!
With Steam Proton enabled and the dll installed the game crashes at initial loading screen.