It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
shmerl: Contacting GOG support directly will probably end up in "we don't support it, so go figure it out yourself", instead of "hey, here is how you can remove Galaxy dependency...".
Try it anyhow.. and tell me how it goes.

Oh, and make sure you give them the same email address that you use for logging in on GOG. Otherwise they can't figure out who you are, even if you link directly to a forum post of yours. And apparently they need to figure out who you are before they can help.
Post edited June 04, 2019 by clarry
avatar
clarry: Try it anyhow.. and tell me how it goes.
Sure, wouldn't hurt contacting them anyway. May be they'll find the right person for this.

UPDATE: I wrote to them explaining this in detail. Let's see what they'll say.
Post edited June 04, 2019 by shmerl
avatar
shmerl: May be not, but it can still reserve memory or something like that. Of course the above was just a suggestion, we don't know for sure it's galaxy that's causing it to run out of the memory.
avatar
Ganni1987: Just finished testing the Steam version, it runs on both WineD3D and DXVK (although randomly freezes due to some missing xaudio ovverrides on my end).

I monitored the Virtual Memory usage and sits happily at about 2.6GB ingame at ultra settings, most likely the game is already large address aware enabled so that patch doesn't help here unfortunately.

Since you can't even get in game, I'd say there is definitely something going on with those Galaxy libraries.
what wine did you use ?
SteamPlay/Proton?
vanilla wine?
avatar
Ganni1987: Just finished testing the Steam version, it runs on both WineD3D and DXVK (although randomly freezes due to some missing xaudio ovverrides on my end).

I monitored the Virtual Memory usage and sits happily at about 2.6GB ingame at ultra settings, most likely the game is already large address aware enabled so that patch doesn't help here unfortunately.

Since you can't even get in game, I'd say there is definitely something going on with those Galaxy libraries.
avatar
immi101: what wine did you use ?
SteamPlay/Proton?
vanilla wine?
Wine Staging 4.9 - self compiled, I didn't test much, only enough to get the game running. Didn't bother to check the cause of the freezes, I noticed an xaudio error in terminal and esync was on.
Post edited June 04, 2019 by Ganni1987
avatar
shmerl: Contacting GOG support directly will probably end up in "we don't support it, so go figure it out yourself", instead of "hey, here is how you can remove Galaxy dependency...".
yeah, I mean, i don't think they even have an option to remove that dependency, when the game is linked against galaxy.dll as you said. I doubt they have access to the source and the permission to change/recompile/distribute the modified exe. Not sure support is going to be much help.
Would be cool if you could get that d9vk developer to provide some more detail on where galaxy is "known to leak file descriptors & memory".
Then post that info on the mantis bugtracker or the galaxy thread. That should get some attention from the galaxy developers (ideally).
avatar
immi101: what wine did you use ?
SteamPlay/Proton?
vanilla wine?
I used vanilla Wine 4.9 + dxvk.
avatar
immi101: what wine did you use ?
SteamPlay/Proton?
vanilla wine?
avatar
Ganni1987: Wine Staging 4.9 - self compiled, I didn't test much, only enough to get the game running. Didn't bother to check the cause of the freezes, I noticed an xaudio error in terminal and esync was on.
just asking because shmerl was using vanilla wine

@shmerl
might be worth giving wine-staging a try? probably faster than waiting for an answer from GOG support :p
avatar
immi101: @shmerl
might be worth giving wine-staging a try? probably faster than waiting for an answer from GOG support :p
Yeah, let me try that. May be staging has some patches to reign in virtual memory overuse.

UPDATE:

Interesting, it didn't crash on mmap this time! Though it's getting stuck on xaudio with just showing a black screen:

====

00ba:err:ntdll:RtlpWaitForCriticalSection section 0x5846f88 "xaudio_dll.c: XA2SourceImpl.lock" wait timed out in thread 00ba, blocked by 00b7, retrying (60 sec)
00b7:err:ntdll:RtlpWaitForCriticalSection section 0x182e0ca0 "?" wait timed out in thread 00b7, blocked by 00ba, retrying (60 sec)

At least that's progress!

I wonder if it's related to faudio, since I've seen somewhere, that staging disables it, while stock wine is using it.

UPDATE 2:

Installing xact with winetricks worked around that. It started! Thanks a lot for the idea. I wonder what exactly staging does to fix it.
Post edited June 05, 2019 by shmerl
avatar
shmerl: ====

00ba:err:ntdll:RtlpWaitForCriticalSection section 0x5846f88 "xaudio_dll.c: XA2SourceImpl.lock" wait timed out in thread 00ba, blocked by 00b7, retrying (60 sec)
00b7:err:ntdll:RtlpWaitForCriticalSection section 0x182e0ca0 "?" wait timed out in thread 00b7, blocked by 00ba, retrying (60 sec)
That's the same error I get with Wine Staging 4.9. The plot thickens

Edit: What if you build Wine Staging without those xaudio reverts?
Post edited June 05, 2019 by Ganni1987
avatar
Ganni1987: Edit: What if you build Wine Staging without those xaudio reverts?
For now I just installed xact with winetricks, and it worked! I can try building staging without faudio reverts. Problem is, it's a major pain to build WoW64 Wine (with 32-bit support) without using some chroot, containers or outright 32-bit VM. So I just never got to set up the build for it yet. I always simply build pure 64-bit Wine when needed. But I might as well go through setting up that mess again.

Wine developers really should figure out how to make it cross-compilable on 64-bit Linux. But I suppose a lot depends on proper multiarch packaging, which is a huge mess in Debian still. I still can't build 32-bit Mesa for example by cross compiling.

How do you build it usually?
Post edited June 05, 2019 by shmerl
avatar
shmerl: How do you build it usually?
I always compile the 64bit on host OS and the 32bit part in a VM, then merge the required files together.

EDIT: I play a lot of 32bit games, so that component is a must for me.
Post edited June 05, 2019 by Ganni1987
avatar
Ganni1987: I always compile the 64bit on host OS and the 32bit part in a VM, then merge the required files together.

EDIT: I play a lot of 32bit games, so that component is a must for me.
I actually compile 64-bit one in VM as well, and Mesa in a separate one, in order not to mess up things accidentally when dealing with some manual tweaks. I'll just add a 32-bit VM to that. I had no need to do it until now, since stock Wine was enough (it's WoW64). But the above case was really weird.
Post edited June 05, 2019 by shmerl
avatar
Ganni1987: I always compile the 64bit on host OS and the 32bit part in a VM, then merge the required files together.

EDIT: I play a lot of 32bit games, so that component is a must for me.
avatar
shmerl: I actually compile 64-bit one in VM as well, and Mesa in a separate one, in order not to mess up things accidentally when dealing with some manual tweaks. I'll just add a 32-bit VM to that. I had no need to do it until now, since stock Wine was enough. But the above case was really weird.
So to understand what you did:

Built Wine with Staging patches and applied xact with winetricks, and now game works "perfectly" so to speak?
avatar
Ganni1987: Built Wine with Staging patches and applied xact with winetricks, and now game works "perfectly" so to speak?
I installed pre-built staging Wine from winehq repo. It's WoW64, so supports 32-bit. And installed xact with winetricks, yes.
For now I have a setup to build 64-bit Wine only (stock / staging, etc.). That's good only for 64-bit games. But I'll probably eventually set up 32-bit VM as well, since using faudio with staging would be better. Can be useful for such weird 32-bit outliers.

I can't say how "perfect" it is, since I didn't get far beyond the loading screen and settings, since I don't plan a major playthrough now (still in the middle of TW3). But I was interested in making it work, after buying the game :)
Post edited June 05, 2019 by shmerl
avatar
shmerl: How do you build it usually?
avatar
Ganni1987: I always compile the 64bit on host OS and the 32bit part in a VM, then merge the required files together.

EDIT: I play a lot of 32bit games, so that component is a must for me.
Out of curiosity, what specs do you use for the VM?

(Also, assuming your kernel can run 32-bit binaries, you could also use a chroot or container for the compiling, avoiding the overhead of a VM. And if your kernel can't run 32-bit binaries, why are you compiling a program that your system can't execute? (Note that not being able to run 32-bit binaries would be highly unusual; it probably means you compiled your own kernel and chose to disable 32-bit support, or you're working with some embedded distribution rather than one meant for desktop/laptop use.))

avatar
shmerl: But I'll probably eventually set up 32-bit VM as well, since using faudio with staging would be better. Can be useful for such weird 32-bit outliers.
Again, you can do this with a chroot or a container and avoid the overhead of a VM.

(Quick way to get a debian chroot: use debootstrap. You may need to copy or hardlink resolv.conf into the chroot if you need network access (in particular, DNS) in it, but otherwise you should be fine for this purpose. Other distributions have similar tools; if you want an Arch or Gentoo chroot, the installation guide will have you setting up a chroot as part of the installation, so you could just follow that part of the guide.)
Post edited June 05, 2019 by dtgreene