Compatibility Report

@kisak-valve This game needs a .NET label too.

This one seems to use some really obscure .NET features, some I've never seen before. But, Proton logs should be more productive now, FWIW.

I get a NotImplementedException, in obfuscated code unfortunately, and with no indication in the stack trace of which method is unimplemented. It turns out that it uses the ComputerInfo class from the Visual Basic libraries. It needs all of the "Memory" properties to be implemented.

Stubbing those out gets it further, to a crash in MOJOSHADER_glEffectBeginPass.

A crash there typically means a program failed to link. BeginPass is pretty big so lots of stuff might happen, but usually that's the cause. An apitrace will probably reveal the problem shader on the final glLinkProgram failure (I believe we store errors from GetProgramInfoLog somewhere in mojoshader_opengl.c, but I don't remember of the top of my head)

After doing the real implementation, the game started without crashing. I'm not sure why. Other than implementing those properties, I did a Mono merge, and I was testing in Wine instead of Proton for convenience.

It still crashes for me in Proton, so it's a fix in upstream Wine or some other difference.

I tested in Wine 4.11 and did not get a MojoShader crash. It seems this is caused by Proton somehow.

I can reproduce the crash in Wine from proton's branch, so it's caused by a patch Proton applied on top of Wine. I will try to bisect.

The ComputerInfo memory implementation is in Wine Mono 4.9.3. I still haven't finished the bisect for the MojoShader crash.

The crash is random.

So afaict there's no difference between Proton and Wine 4.11, both just randomly crash in MojoShader sometimes.

Do we have a +relay trace with MojoShader calls? That'll at least give us the stream of shader calls to pin down where it's dying (could be parsing, compiling, constant buffer sets, etc).

Another possibility is an issue in the effect; if we're using the very latest revision then we can dump the effects from here (buf and _len)...

https://github.com/FNA-XNA/MojoShader/blob/fna/mojoshader_effects.c#L838

... and run the binaries through the test util:

https://github.com/FNA-XNA/MojoShader/blob/fna/utils/testparse.c

I wasn’t able to crash the game with 4.11-8’s FNA revision. I may have fixed this by accident...?

System Information

• GPU: RX 6600
• Video driver version: Mesa 25.0.7 / LLVM 20.1.2
• Kernel version: 6.8.0-86-generic
• Link to full system information report as Gist
• Proton version: 9.0-4

I confirm:

• [x] that I have checked whether there are updates for my system available.

Symptoms

I tested two ProtonDB reports with my GOG copy: the first one reporting that the game didn't run on the 9.x series, and the second stating that keyboard input crashed the game. The first one I was unable to replicate, as the game ran just fine with gamepad input (but produced such a large log that GitHub apparently won't take it), whereas poking around with some keyboard input quickly made the game crash with an error window.

steam-18441501327423963136_keyboard.log

And here's a crash log for good measure. I'm not certain if it's from the exact session I ran in the above proton log, but it's of the same bug.
crashlog20251028221024.txt

Reproduction

Launch the game and keep pressing keys until the error window pops up.

I can confirm the same issue with keyboard input on my oled steam deck. If I launch it and try typing with the virtual keyboard I can get the game to crash silently to the library

The library looks for some private methods from XNA named KeyboardState.AddPressedKey and RemovePressedKey, and crashes when it can't find them. These are easy to add, and they fix the crash. But, keyboard input still doesn't seem to do anything.

Keyboard input no longer seems to crash the game on proton Experimental, keyboard input doesn't do much else atm though