| View previous topic :: View next topic |
| Author |
Message |
Darkyyo
n00b
Joined: 27 Sep 2022
Posts: 32
|
 Posted: Sat Jun 22, 2024 6:31 pm Post subject: [SOLVED] Proton/WINE-GE can't start Touhou games via THCRAP |
 |
|
Note: This thread originally concerned only WINE-GE, but as I dug deeper, I found that the issue affected just about anything Proton (itself or derivatives), so I changed the title to something broader and more accurate.
To preface, THCRAP actually does manage to patch and launch the Touhou executables when I use wine-vanilla or wine-staging 9.0. However, in Sway (Wayland), both of these builds launch the games in tiny 640x480 windows, which when viewed in fullscreen, are stretched irregularly; not preserving their 4:3 aspect ratio. This led me to find out about "wine-ge-custom", a build for non-Steam games that comes with an fshack patch that fixes this. Unfortunately, when I try to use the "lutris-GE-Proton8-26-x86_64" binary in the official repo to:
- start up a Touhou game directly (THCRAP still used to patch it, updates are simply disabled) or
- start up THCRAP and its updater window, and then click on the "Run the game" button,
I am met with this error log. The part of interest is everything from "Unhandled exception 0x80000004..." onwards. For the first case in the above list I get this printed first:
| Code: | | wine: Unhandled exception 0x80000004 in thread 138 at address 0045D748 (thread 0138), starting debugger... |
with this being printed first instead for the second case (every time I click on the "Run the game" button):
| Code: | | wine: Unhandled page fault on write access to F807E6A0 at address 0045D746 (thread 02b4), starting debugger... |
I also tried using wine-proton 9.0.1 (surprise: it also has the fshack patch), which gave me more or less the same errors, except for this one:
| Code: | | Unhandled exception: page fault on read access to 0x46ffa068 in wow64 32-bit code (0x0045d746). |
There seems to be a trend of anything with "proton" in its build name having similar issues. Having checked the error codes in /usr/include/wine-vanilla-9.0/wine/windows/winerror.h, "errno 38" apparently refers to "ERROR_HANDLE_EOF".
Here's also the logs for THCRAP when run with wine-vanilla and wine-ge separately. You can see that while wine-vanilla finishes successfully with a "Removing plugins" message, wine-ge stops short at the last "Initializing" section, before it can resolve the files marked with "(Data)", "(Text)", "(PNG)", etc.
Out of curiosity, I decided to run some (dumb) tests. If I go on a Linux Mint live environment, install native Lutris (for its dependencies), mount my local drive, and then run the wine-ge binary from the directory I extracted/unzipped back in Gentoo, it all works. Even if I log out there and then enter a Cinnamon Wayland session, it works. In fact, it's here where I found out that while wine-vanilla and wine-staging automatically fullscreen the games with the correct aspect ratio in X11, they continue to launch them in windowed mode in Wayland. That could hint to some workaround with Xwayland... Anyway, I got the same results with an EndeavourOS live environment (dependencies from partly installed wine-ge-custom package). All in all, that specific wine-ge directory seems to be uncorrupted/untampered.
Back in Gentoo, the binary can run any other game, even the Touhou ones directly (no THCRAP involved). I can only assume that there's some very specific USE flag, package, or kernel option that may be missing or hindering wine-ge-run THCRAP's ability to patch the games. Does anyone have any clues on what it might be? Maybe something is bound to change if I compile wine-ge?
kernel .config
emerge --info
I've also looked into Gamescope as an alternate means to preserve window aspect ratio. It just gave me this vague error:
| Code: | gamescope: children shut down!
gamescope: ../gamescope-3.14.18/src/backend.cpp:60: virtual gamescope::CBaseBackendFb::~CBaseBackendFb(): Assertion `!HasLiveReferences()' failed. |
whose discussion I suppose would be better suited to a separate thread. If I run it directly on the games, it makes their display pixelated and CPU-intensive, which coincides with Gamescope's alleged poor Intel GPU support.
Last edited by Darkyyo on Wed Jun 26, 2024 10:26 pm; edited 1 time in total |
|
| Back to top |
|
 |
Darkyyo
n00b
Joined: 27 Sep 2022
Posts: 32
|
| Posted: Wed Jun 26, 2024 10:06 pm Post subject: |
|
|
Following the above suspicion, I spent about a week tinkering with all sorts of possibly relevant packages and USE flags. All I found were more vague exceptions; however, there was a theme of a lack of memory read/write access. It stuck out especially when I kept getting the error: | Code: | | No access to memory location. |
I could change all the permissions I wanted, but it would persist. It's not even like THCRAP couldn't get to the executables, since I would get different errors if the expected file was different or absent.
Frustrated with my lack of success, I decided to commit heresy and install gentoo-kernel-bin... And that was all it took: something that this kernel's .config had allowed THCRAP to properly interact with the games via wine-proton. This prompted me to try and narrow down the possibly responsible options. I took the dist-kernel's .config, ran: | Code: | | make localmodconfig |
and then compiled it, but it ceased to fix the problem. Moreover, with the resultant (dist) .config and my own diff'd from the main dist .config, I was still left with 5000+ possibilities. I was thinking about posting them here for more arbitrary detail, but then I remembered (long ago) I had partly followed some advice on kernel optimizations from this Mental Outlaw video. He changed some number-based options that I was hoping to restore to their defaults, but something else caught my eye:
| Code: | CONFIG_CROSS_MEMORY_ATTACH:
Enabling this option adds the system calls process_vm_readv and
process_vm_writev which allow a process with the correct privileges
to directly read from or write to another process' address space. |
which finally fixed everything.
I need to fix my .config version control: what I thought was the "default with WiFi and sound drivers" .config, that should have had this option enabled by default, had other stuff disabled as well. Any thoughts on whether I should continue to follow the video? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gamers & Players
