https://bugs.winehq.org/show_bug.cgi?id=53732
Bug ID: 53732 Summary: Ghost Master: ReShade hook doesn't load properly (no UI) Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs@winehq.org Reporter: varrok@gmail.com Distribution: ---
Created attachment 73167 --> https://bugs.winehq.org/attachment.cgi?id=73167 Wine output while the game's run by cli
Hi, I'm new here!
Having issue with an old 2003 OpenGL-based (probably OGL1.x) game, Ghost Master. While the game by itself runs mostly fine (bar WMV cutscenes), it doesn't have any form of anti-aliasing (nor does wine seem to be able to force it like you could on Windows), so I tried using ReShade to achieve it. Sadly, even though the game launches correctly from ReShade's own OPENGL32.dll implementation (made sure of that), its (imgui-powered) ui does not appear at all during runtime. Tried the same steps on my Win10 VM, and it renders correctly there.
Specs: Arch Linux 5.18.16-arch1-1 Nvidia GTX 1080 (properitary Nvidia drivers 515.65.01)
What I tried: - current stable wine version - current dev wine version = wine-7.18-37-g2a4ec7dafc7 - both 32bit and 64bit wine prefixes - renaming all non-Reshade Opengl32.dll files in a paranoid attempt to force it to use the one I wanted (worked)
How to reproduce: - Install the game (demo for convenience: https://www.fileplanet.com/archive/p-14042/Ghost-Master-Demo-English [issue happens there too]) - Download Reshade http://reshade.me/ (Possibly any, tested on 5.4.2; the site seems to have problems running, so mirror: https://www.techspot.com/downloads/7206-reshade.html ) - Run Reshade, go through the GUI installer, selecting ghost.exe -> OpenGL api -> any addons -> to finish - Launch game - Notice lack of Reshade UI
https://bugs.winehq.org/show_bug.cgi?id=53732
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #1 from Béla Gyebrószki gyebro69@gmail.com --- You need to override opengl32.dll to native,builtin otherwise Wine uses it's own (builtin) opengl32. Create a new profile for 'ghost.exe' in winecfg's Application tab and override opengl32.dll to native,builtin in the Libraries tab. In this manner ReShade's UI is visible after starting the game, tried with Ghost Master from GOG.
https://bugs.winehq.org/show_bug.cgi?id=53732
varrok@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #2 from varrok@gmail.com --- @(In reply to Béla Gyebrószki from comment #1)
You need to override opengl32.dll to native,builtin otherwise Wine uses it's own (builtin) opengl32. Create a new profile for 'ghost.exe' in winecfg's Application tab and override opengl32.dll to native,builtin in the Libraries tab. In this manner ReShade's UI is visible after starting the game, tried with Ghost Master from GOG.
Thank you very much for the quick and on point response.
It worked, which confuses me to a great extent, as I don't know why it didn't work before. From my understanding, the default setting can be boiled to: "search wine's opengl32.dll, then if something is not present there, use the 3rd party one".
I thought that if I remove the wine's opengl32.dll (drive_c/Windows/system32/opengl32.dll and syswow64/opengl32.dll) it would fallback to reshade's dll, yet it produces a different outcome than your solution. Furthermore, if I then remove/rename the reshade's dll as well, the game would fail to launch, so surely it does access the reshade file.
I'll mark this as resolved, but an explanation would probably help me make fewer mistakes in the future.
https://bugs.winehq.org/show_bug.cgi?id=53732
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- (In reply to varrok from comment #2)
It worked, which confuses me to a great extent, as I don't know why it didn't work before. From my understanding, the default setting can be boiled to: "search wine's opengl32.dll, then if something is not present there, use the 3rd party one".
I thought that if I remove the wine's opengl32.dll (drive_c/Windows/system32/opengl32.dll and syswow64/opengl32.dll) it would fallback to reshade's dll, yet it produces a different outcome than your solution. Furthermore, if I then remove/rename the reshade's dll as well, the game would fail to launch, so surely it does access the reshade file.
I'll mark this as resolved, but an explanation would probably help me make fewer mistakes in the future.
The native/builtin logic only controls loading of the entire dll, not individual exports. If exports are missing from the DLL that's loaded, things will just fail. (We can't implement it the way you're thinking, either.)
Builtin DLLs are loaded regardless of the content of the DLL file on disk. In fact, builtin DLLs are never loaded from the prefix; they're always loaded from the install directory (e.g. in /usr/lib/) or from the build tree. The copy in the prefix only exists because some programs expect (some) libraries to exist on-disk and to match the in-memory image.
However, we don't load builtins if the file on disk is absent entirely. This is basically because programs expect this behaviour.
In essence you can think of it like transparently swapping out the on-disk DLL for the builtin one from the install/build directory if builtin load order is specified.
https://bugs.winehq.org/show_bug.cgi?id=53732
--- Comment #4 from varrok@gmail.com --- (In reply to Zeb Figura from comment #3)
(In reply to varrok from comment #2)
It worked, which confuses me to a great extent, as I don't know why it didn't work before. From my understanding, the default setting can be boiled to: "search wine's opengl32.dll, then if something is not present there, use the 3rd party one".
I thought that if I remove the wine's opengl32.dll (drive_c/Windows/system32/opengl32.dll and syswow64/opengl32.dll) it would fallback to reshade's dll, yet it produces a different outcome than your solution. Furthermore, if I then remove/rename the reshade's dll as well, the game would fail to launch, so surely it does access the reshade file.
I'll mark this as resolved, but an explanation would probably help me make fewer mistakes in the future.
The native/builtin logic only controls loading of the entire dll, not individual exports. If exports are missing from the DLL that's loaded, things will just fail. (We can't implement it the way you're thinking, either.)
Builtin DLLs are loaded regardless of the content of the DLL file on disk. In fact, builtin DLLs are never loaded from the prefix; they're always loaded from the install directory (e.g. in /usr/lib/) or from the build tree. The copy in the prefix only exists because some programs expect (some) libraries to exist on-disk and to match the in-memory image.
However, we don't load builtins if the file on disk is absent entirely. This is basically because programs expect this behaviour.
In essence you can think of it like transparently swapping out the on-disk DLL for the builtin one from the install/build directory if builtin load order is specified.
I really appreciate the explanation, thanks! It's all clear
https://bugs.winehq.org/show_bug.cgi?id=53732
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Austin English austinenglish@gmail.com --- Closing.
-
WineHQ Bugzilla