http://bugs.winehq.org/show_bug.cgi?id=59248 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 80982 --> http://bugs.winehq.org/attachment.cgi?id=80982 Screenshot of window resize dimensions compatible for gameplay mouse clicks (pics show DAMAVAND/vk without and with color/swap fix patch but WINED3D/gl default renderer also works) Attached are screenshots showcasing window dimensions that support compatible mouse click extents for gameplay. I did not find any in-game display settings which is odd. Confirmed for wine-11.9-0c0d2643208 for both x11 and wayland for both WINED3D/gl and DAMAVAND/vk renderers for game version 1.0.1.1180. Game also auto pulls updates from network which have their own versions displayed for splash screen which may cause different behaviors over time. For this test update 1.1.46.209741.218510 upgraded to 1.1.59.209741.220002. Mouse clicks do not register despite game being aware of mouse move positions which is apparent by hovering over the skip button (top right during intro video) which changes color and holding Ctrl while moving mouse during gameplay which displays an orange circle beneath cursor (holding Alt handles offsetting orange circle). Mouse clicks fixed by resizing window to compatible dimensions. Simply double clicking the window title during intro video resizes window to dimension which registers mouse click for skip video button for Debian 13. However that dimension only registers mouse clicks for a small extent from the top of the screen that the skip video button falls within and does not extend to the initial gameplay choose buttons and requires manual resize for mouse clicks to be registered to extent of gameplay buttons farther from the top of the screen. Resize seems necessary after window loses focus (such as Alt+Tab away and back) to re-trigger mouse click fix again. Other findings: DAMAVAND/vk renders graphics darker also showcased for screenshots and fixed via merge request patch that supports flip swap effect 0x3 with more than 1 back buffer: https://bugs.winehq.org/show_bug.cgi?id=45364#c13 https://gitlab.winehq.org/wine/wine/-/merge_requests/10567/ MangoHUD seems incompatible for WINED3D/gl renderer for wayland and causes err logs to be spammed indefinitely which do not happen when launched without MangoHUD: 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glUniformMatrix(non-matrix uniform)". 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glBufferData(immutable)". 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glBufferData(immutable)". 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glBufferData(immutable)". 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glBufferData(immutable)". 0478:err:d3d:wined3d_debug_callback 00007F5C610C80A0: "GL_INVALID_OPERATION in glUniform(location=1)". Despite the err logs also appearing for x11, MangoHUD still appears unlike wayland which is only shown briefly during spashscreen before disappearing. Similar err logs have been reported for other games but unclear if they were caused by MangoHUD which is fairly useful for debugging game bugs so it seems worth mentioning that it may be the cause of err logs for some games in which case those games should be tested without MangoHUD to check different behavior. Other than these differences between WINED3D/gl and DAMAVAND/vk, the two renderers seems to run the game fairly consistently. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.