https://bugs.winehq.org/show_bug.cgi?id=42999
Bug ID: 42999 Summary: 3D Engine in NosTale not reacts for mouse on Mac Product: Wine-staging Version: 2.7 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: artrixdev@gmail.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de
Created attachment 58140 --> https://bugs.winehq.org/attachment.cgi?id=58140 Simple logs from cmd and graphic bug in game.
If try change camera position nothing to do and if I clicked on items in equipment it's changing to "question mark" graphic.
https://bugs.winehq.org/show_bug.cgi?id=42999
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- Not major, see bug reporting guidelines. Are you sure that the test was done with a Wine Staging version (check "wine --version"). The typical messages are missing in the terminal output.
https://bugs.winehq.org/show_bug.cgi?id=42999
Patryk Szczepański theszczepancio@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theszczepancio@gmail.com
--- Comment #2 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 58478 --> https://bugs.winehq.org/attachment.cgi?id=58478 Log of bug
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #3 from Patryk Szczepański theszczepancio@gmail.com --- I added log of Nostale launch at wine 2.10 dev (the bug also occurs in Wine staging). Hope it helps.
https://bugs.winehq.org/show_bug.cgi?id=42999
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine
--- Comment #4 from Michael Müller michael@fds-team.de --- The bug is not specific to Wine Staging and also occurs with the development version, moving it into the Wine product.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #5 from Patryk Szczepański theszczepancio@gmail.com --- Still it doesn't work, even with Wine 3.0 from brew and native dx9 libs installed via winetricks.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #6 from Patryk Szczepański theszczepancio@gmail.com --- Can confirm that bugs still appears in wine 3.13, compiled with brew install --devel wine (without xquartz).
I installed with winetricks ie8 and newest dx9 from dll repo. Probably best fix would be moving to vulkan based rendering and vk9/dxvk, but who knows, we will see.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #7 from Patryk Szczepański theszczepancio@gmail.com --- I found that this bug appeared on Linux too before 1.7.7 version: https://www.winehq.org/announce/1.7.7 So theres probably an idea how to fix on Mac.
Installing dinput8 does not change anything.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #8 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 61922 --> https://bugs.winehq.org/attachment.cgi?id=61922 Wine 3.13 log
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #9 from Patryk Szczepański theszczepancio@gmail.com --- I uploaded two logs of wine 3.19 staging with macdriver set to XQuartz. I tried to change some options with winetricks (ddr, csmt, ao, multisampling, mwo, rtml and many other), also I tried to install dinput, dinput8, vcrun2008, directx9, and nothing helped. Probably (what I think) causing bug is this error:
002b:err:plugplay:runloop_thread Couldn't open IOHIDManager.
The bug does not appear on Linux anymore, on whatever version I tested in under Arch Linux it works fine.
If you have something that I can check just write it here :) Good night and have nice time improving Wine products!
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #10 from Patryk Szczepański theszczepancio@gmail.com --- I uploaded two logs of wine 3.19 staging with macdriver set to XQuartz. I tried to change some options with winetricks (ddr, csmt, ao, multisampling, mwo, rtml and many other), also I tried to install dinput, dinput8, vcrun2008, directx9, and nothing helped. Probably (what I think) causing bug is this error:
002b:err:plugplay:runloop_thread Couldn't open IOHIDManager.
The bug does not appear on Linux anymore, on whatever version I tested in under Arch Linux it works fine.
If you have something that I can check just write it here :) Good night and have nice time improving Wine products!
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #11 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 62762 --> https://bugs.winehq.org/attachment.cgi?id=62762 Wine 3.19 Staging Nostale Log
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #12 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 62763 --> https://bugs.winehq.org/attachment.cgi?id=62763 Another Nostale Wine 3.19 Staging log
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #13 from Patryk Szczepański theszczepancio@gmail.com --- Ahh I am bit sleepy, I didn't set macdriver to exacly xquartz but to x11 instead (if somebody is "strict").
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #14 from Patryk Szczepański theszczepancio@gmail.com --- This bug still appears on CrossOver 21.1 version (I can't use plain wine since I'm testing it on M1 mac with Monterey). Also the performance is bad, but the task is for CodeWeavers team, since they integrate DXVK with MoltenVK.
So, I add another log, directly from CrossOver logging option.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #15 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 71878 --> https://bugs.winehq.org/attachment.cgi?id=71878 CrossOver 21.1 NosTale log
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #16 from Patryk Szczepański theszczepancio@gmail.com --- The game is still not working on CrossOver 21.2 version, too.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #17 from Patryk Szczepański theszczepancio@gmail.com --- Issue still happens on CrossOver 22 Nightly Builds.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #18 from Patryk Szczepański theszczepancio@gmail.com --- Issue still happens even on CrossOver 22 beta1, which is using Wine 7.7 - I made another debug log (maybe will be useful) since this revision has major wine upgrade (previous version was using 6.0).
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #19 from Patryk Szczepański theszczepancio@gmail.com --- Created attachment 72767 --> https://bugs.winehq.org/attachment.cgi?id=72767 CrossOver 22 beta1 NosTale cxlog
https://bugs.winehq.org/show_bug.cgi?id=42999
ekzan ihsanmertorengul@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ihsanmertorengul@hotmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #20 from Patryk Szczepański theszczepancio@gmail.com --- Okey, so with help of my friend (morsisko) we finally fixed the mouse bug on macOS with custom wine build.
The custom CrossOver wine executables with fix can be downloaded here: https://github.com/PSzczepanski1996/macos-crossover-wine-nostale-builder
The patch that we wrote is placed here: https://github.com/PSzczepanski1996/macos-crossover-wine-nostale-builder/blo...
Why we must do that? Because game for some reason is checking memory regions preventing it's own odd logic from calling system memory. It checks if the code is called under "0x70000000" range, but for some reason `user32.dll` is placed here under Wine causing mouse bug, graphical glitches and other memory-releated errors.
Not sure if we should set constant values for `user32.dll` and other libraries in Wine or mix them via some randomizer like it's done in ALSR: https://user-images.githubusercontent.com/21007545/210278824-29f42d90-aca4-4...
But this is thread to discuss since I'm not familiar with Wine development.
https://bugs.winehq.org/show_bug.cgi?id=42999
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #21 from Austin English austinenglish@gmail.com --- (In reply to Patryk Szczepański from comment #20)
Okey, so with help of my friend (morsisko) we finally fixed the mouse bug on macOS with custom wine build.
The custom CrossOver wine executables with fix can be downloaded here: https://github.com/PSzczepanski1996/macos-crossover-wine-nostale-builder
The patch that we wrote is placed here: https://github.com/PSzczepanski1996/macos-crossover-wine-nostale-builder/ blob/main/nostale.patch
Why we must do that? Because game for some reason is checking memory regions preventing it's own odd logic from calling system memory. It checks if the code is called under "0x70000000" range, but for some reason `user32.dll` is placed here under Wine causing mouse bug, graphical glitches and other memory-releated errors.
Not sure if we should set constant values for `user32.dll` and other libraries in Wine or mix them via some randomizer like it's done in ALSR: https://user-images.githubusercontent.com/21007545/210278824-29f42d90-aca4- 4df4-8288-55ba7e23108f.png
That's done for a few dlls in wine: $ git grep EXTRADLLFLAG.*image-base dlls/kernel32/Makefile.in:EXTRADLLFLAGS = -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b600000 dlls/kernelbase/Makefile.in:EXTRADLLFLAGS = -nodefaultlibs -nostartfiles -Wl,--image-base,0x7b000000 dlls/ntdll/Makefile.in:i386_EXTRADLLFLAGS = -Wl,--image-base,0x7bc00000 dlls/ntdll/Makefile.in:x86_64_EXTRADLLFLAGS = -Wl,--image-base,0x170000000 dlls/opengl32/Makefile.in:EXTRADLLFLAGS = -Wl,--image-base,0x7a800000 dlls/riched20/Makefile.in:EXTRADLLFLAGS = -Wl,--image-base,0x7ac00000 dlls/wow64/Makefile.in:EXTRADLLFLAGS = -nodefaultlibs -Wl,--image-base,0x6f000000 dlls/wow64cpu/Makefile.in:EXTRADLLFLAGS = -nodefaultlibs -Wl,--image-base,0x6f100000 dlls/wow64win/Makefile.in:EXTRADLLFLAGS = -nodefaultlibs -Wl,--image-base,0x6f200000
It's discouraged, but if there is an application that depends on it, it's possible to hardcode it.
But this is thread to discuss since I'm not familiar with Wine development.
In general though, policy questions like this are better suited for wine-devel@winehq.org (or for coding questions, in a merge request on gitlab ;))
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Hopefully fixed by the dynamic base support, please retest.
https://bugs.winehq.org/show_bug.cgi?id=42999
--- Comment #23 from Patryk Szczepański theszczepancio@gmail.com --- And it's probably fixed, works fine on CrossOver 24 beta1 :)