Compatibility Report

With Experimental/Hotfix I also getting another exception:

Can't copy for some reason

@kisak-valve I'm the game author - I've released a patch which fixes the above crash, but for the sake of visibility I'll list here all the issues I've been having, which I've had to come up with workarounds for. If you'd prefer, I could open separate bug trackers for them all. I'm concentrating on Steam Deck rather than Proton per se.

• Using Proton Experimental on my Steam Deck last week, the game ran much more slowly than other Proton builds. I don't know why that is and haven't really looked into it, I'm just hoping it goes away in the final version.

• Using Proton 9.0-3, the game crashed on title screen with this error: "ShaderFunction29:61:44: E5017: Aborting due to not yet implemented feature: Dereference with non-constant offset of type HLSL_IR_EXPR". This is in my skinned mesh shader, I'm passing the bones in to the shader, in their current animation state, as an effect parameter (a Matrix array). My workaround was to put the bone matrices into a texture and pass that to the shader instead, but that's horribly inefficient and will cause performance problems if there are a lot of characters on-screen at once. (This problem was not in earlier Proton version, and also appears to have been fixed in Proton Experimental)

• The VFACE shader semantic is broken. I think this was introduced in Proton 9.0-3. This caused graphical glitches.

• Steam Deck (and Proton) doesn't support multiple audio listeners, as reported in the comment above. The game has a small window where the characters heads appear and I normally use a second audio listener for that - I had to disable this on Steam Deck.

• In earlier Proton builds (7.0-6) I found that the game stalled every 10 seconds on Steam Deck. I fixed this by removing the call to base.Update from the main GameImpl.Update function (where GameImpl is derived from Microsoft.Xna.Framework.Game). I don't know what it does in there, hopefully not garbage collection. My research at the time indicated it was updating "game components", but I haven't registered any. (Haven't retested this in 9.0-3)

• In earlier Proton builds (7.0-6) Steam Deck hangs when calling Texture2D.SetData if not on the main thread. My workaround was to use the main thread but it's less performant presumably (fortunately the Steam Deck is fast!). (Haven't retested this in 9.0-3)

• I also had to move a bunch of calculations onto the main thread, that I normally put on worker threads, as I found the worker threads were hanging on Steam Deck. That was also 7.0-6 and I haven't retested in 9.0-3.

• A number of functions involving floating point math give different output on Steam Deck to PC. This is a problem because my game uses a deterministic network model - in effect, it only passes the controller input packet across the network every frame and expects the game simulation to be identical on all machines. (I call _controlfp_s on every thread I start to harmonize float settings). Here are the functions I've had problems with:

Matrix.CreateWorld
Matrix.CreateFromAxisAngle
Quaternion.Slerp
Ray.Intersects(BoundingBox)
MathHelper.ToDegrees

My workaround was to replace these functions with hand-written ones. I guess I'm worried there might be other functions with non-deterministic outputs though, which are less quick to reproduce errors. I wonder why it's happening, when it doesn't happen with my other game that uses the same network model, but with Unity. Perhaps you're using the equivalent of fp:fast instead of fp:precise under the hood or something like that?

I'm not knowledgeable on a lot of this so maybe @flibitijibibo can comment.

It's not unexpected for floating point math to be different, because the implementation of library functions is different. In this case we're using FNA to replace XNA, but there have also been similar networking issues in other games caused by the C standard library.

It is possible to use XNA by setting launch options of WINE_MONO_OVERRIDES=Microsoft.Xna.Framework.*,Gac=y %command%, but that may have its own set of problems.

@alasky17 is looking at the performance issues.

• Using Proton 9.0-3, the game crashed on title screen with this error: "ShaderFunction29:61:44: E5017: Aborting due to not yet implemented feature: Dereference with non-constant offset of type HLSL_IR_EXPR". This is in my skinned mesh shader, I'm passing the bones in to the shader, in their current animation state, as an effect parameter (a Matrix array). My workaround was to put the bone matrices into a texture and pass that to the shader instead, but that's horribly inefficient and will cause performance problems if there are a lot of characters on-screen at once. (This problem was not in earlier Proton version, and also appears to have been fixed in Proton Experimental)

This can be mitigated for now by including redistributable versions of d3dcompiler*.dll with your game. Our re-implementation is making rapid progress but there's a lot of things to implement.

The VFACE shader semantic is broken. I think this was introduced in Proton 9.0-3. This caused graphical glitches.

What exactly is broken? What should we look at?

A number of functions involving floating point math give different output on Steam Deck to PC. This is a problem because my game uses a deterministic network model - in effect, it only passes the controller input packet across the network every frame and expects the game simulation to be identical on all machines. (I call _controlfp_s on every thread I start to harmonize float settings).

Matching the implementations is something we've spent a lot of time on and it's extremely hard to do. Some games do ship redistributable ucrtbase to workaround this.

https://www.codeweavers.com/blog/rbernon/2022/9/12/ucrtcringedll-reverse-engineering-ucrtbasedll-for-pain-and-non-profit

Interesting thanks both for the info!

The VFACE shader semantic is broken. I think this was introduced in Proton 9.0-3. This caused graphical glitches.

What exactly is broken? What should we look at?

Just that it seems to be 0 when it should be 1 for most faces and -1 for backfaces rendered as two-sided, e.g. RasterizerState = RasterizerState.CullNone. Looks like I was using it for stuff like the leaves of plants.

I have a pixel shader that looks something like this (I simplified it a bit):

float4 BasicModelPS(BasicModelVSOutput input, float vface : VFACE) : COLOR0
{
    float4 color = tex2D(TexSampler, input.TexCoord.xy);

    float3 normal = input.Normal * vface;

    float3 light = GetLighting_DiffuseOnly(input.ShadowUV, normal, ShadowMapSampler, ShadowMapParams, LightDirection, LightDiffuseColour, LightAmbientColour);
    color.rgb *= light;
    
    return color;
}

My fix was to stop multiplying input.Normal by vface on Steam Deck. That means the back faces of some plant leaves will have incorrect normals (which to be honest will probably not be very noticeable).

Matching the implementations is something we've spent a lot of time on and it's extremely hard to do. Some games do ship redistributable ucrtbase to workaround this.

https://www.codeweavers.com/blog/rbernon/2022/9/12/ucrtcringedll-reverse-engineering-ucrtbasedll-for-pain-and-non-profit

That won't help in this case, as the listed types are in FNA.

@lolznoob I did not notice any difference in performance between 9.0-3 and expeirmental-9 on the steam deck. I'm not great at the game, so I did not get to a point where I'd have a ton of characters onscreen at once 😅 If you are still seeing this difference, could you give me the exact experimental version you are using (cat version in the common/Proton - Experimental folder would do the trick) and any tips about how to get to a point where the perf drops?

Also - is your workaround for the VFACE shader semantic gated behind SteamDeck=1? I was trying the game out on Linux desktop which shouldn't have any of the deck only workarounds with Proton 9.0-3 and experimental-9, and the plants were looking the same as Windows to me. I'm wondering if there is some way for me to trigger the VFACE shader issue so that we can potentially try to fix the bug in Proton.

@lolznoob I did not notice any difference in performance between 9.0-3 and expeirmental-9 on the steam deck. I'm not great at the game, so I did not get to a point where I'd have a ton of characters onscreen at once 😅 If you are still seeing this difference, could you give me the exact experimental version you are using (cat version in the common/Proton - Experimental folder would do the trick) and any tips about how to get to a point where the perf drops?

You're right, I'm not seeing it anymore. I swear it happened the other week! It was very easy to reproduce and very visible when it happened, you just had to start a new game and walk forward, no gameplay required. Well, maybe I did something strange on my end. Sorry for the false alarm, I guess that's one less thing to worry about.

Also - is your workaround for the VFACE shader semantic gated behind SteamDeck=1? I was trying the game out on Linux desktop which shouldn't have any of the deck only workarounds with Proton 9.0-3 and experimental-9, and the plants were looking the same as Windows to me. I'm wondering if there is some way for me to trigger the VFACE shader issue so that we can potentially try to fix the bug in Proton.

Run the game with force_not_steam_deck in the launch options. You will see the buildings are unusually dark because they use the same shader and vface is 0, so they are treated as though in shadow. But you'll only be able to see this on the first building, the grey bunker you start in front of, as the game will crash almost immediately due to trying to use multiple audio listeners. (Also I did notice it was running unusually slowly, in the 3 seconds before it crashed! hmm. This was Proton Experimental on Steam Deck with force_not_steam_deck in launch options. Version is 1727105898 experimental-9.0-20240918b)

Here's where the Apply3D call breaks:

https://github.com/FNA-XNA/FNA/blob/master/src/Audio/SoundEffectInstance.cs#L273

I'm not sure what the behavior is supposed to be though - does it just multiply the matrix coefficients for each listener together...?