Space Engineers - 244850

[MagicRB]

The latest version of Space Engineers from steam, with app id 244850 seems to require a patch which wine-staging has.

Yes, I did leave out my system specs as it's not important to this issue. (Proton 3.16)

I confirm:

• [x] that I haven't found an existing compatibility report for this game. (Not specifically for this game, and not specifically this error, though it can be seen as a fixme)
• [x] that I have checked whether there are updates for my system available.

Symptoms

Space Engineers uses the GetCurrentPackageId function. SE crashes with en error, which says that the function was invoked with an incorrect parameter. This is caused by a bug in wine which has been ignored, wine-staging does include a patch to solve this problem. I'm not experienced enough to submit a pull request, nor I'd be able to compile proton as I'm kind of incompetent.

Reproduction

Reproduction is really easy, download Space Engineers from steam, install .net 4.7 as described here. After a successful installation of .net and with transform feedback working, you should get an error message like this

Unhandled Exception: 00bb:fixme:ver:GetCurrentPackageId (0x53a800 (nil)): stub System.ArgumentException: Parameter is not valid. at System.Drawing.Image.get_Flags() at System.Windows.Forms.ControlPaint.IsImageTransparent(Image backgroundImage) at System.Windows.Forms.Control.set_BackgroundImageLayout(ImageLayout value) at Sandbox.MyMessageBoxCrashForm.InitializeComponent() at Sandbox.MyMessageBoxCrashForm..ctor(String gameName, String logPath) at Sandbox.MyErrorReporter.ReportGeneral(String logName, String gameName, String id) at Sandbox.MyCommonProgramStartup.PerformReporting() at SpaceEngineers.MyProgram.Main(String[] args) wine: Unhandled exception 0xe0434352 in thread bb at address 0x7b44b08c (thread 00bb), starting debugger... Unhandled exception: 0xe0434352 in 64-bit code (0x000000007b44b08c).

This can easily be solved by either getting the patch upstream to wine (there might be a good reason why it's not upstream) or we could apply the patch directly to proton.

[MagicRB]

BTW I can confirm that Space Engineers does, in fact, work with wine, as I was able to start SE with wine-staging 3.18 without dxvk. It does crash as the wined3d11 API was not capable of running SE for long enough to actually play, it seemed to crash at random points in time, but this does indicate to me that SE should be functional, once we patch proton.

[MagicRB]

I tried locating the patch that makes it work under wine-staging, but I was not able to do so. I'm either completely blind or it doesn't exist. It may be that the function not working is a bi-product of some other bug. I'll continue searching

[MagicRB]

Now I have figured out that SE does crash because of something different, and that function is broken on both wine versions, now I shall figure why does it crash in the first place.

[MagicRB]

I have decompiled SE and I have figured out where is the problematic code path, it seems that SE thinks that '-report' was passed as a command line argument, but from what I understand from the decompiled source, there should not be a reason for SE to think that.

[PeacheyMcKeitch]

Ive posted a link to this thread onto the official Space Engineers support page. Will see if anyone over there has any ideas.

Also go upvote that thread on there forum to try get there attention incase its a SE and not a wine issue!

https://support.keenswh.com/spaceengineers/general/topic/improve-compatibility-with-steam-play-and-proton-linux-mac

[MagicRB]

No, you misunderstood me, let me explain a bit more. SE uses .NET 4.7.1 which IS broken in wine, but it can be made to run with a workaround and a bit of luck. Here is the workaround needed. Then, SE uses Stream Output / Transform Feedback, which is a deprecated feature in DX11, and was probably carried over from the DX9 renderer, which SE has used in the past. Now, Vulkan has recently received this extension "VK_EXT_transform_feedback", which allows Stream Output to work in Vulkan, therefor DXVK now supports Transform Feedback, therefor SE should work in wine, but wine still needs patches to expose this extension. Proton has these patches already, I think, I'm not sure, don't quote me. Mainline wine will get at the next release at it has been already staged which means wine-staging will get it too. Now wine-staging has a patch in place which enables SE to start under opengl, it still crashes as opengl is not capable of sustaining the graphics engine. The problem in proton is not related to Transform Feedback. I can't identify the patch that is responsible for this, as I actually do not know what's the problem. I have decompiled SE and looked at the code which is causing the crash, based on the stacktrace provided by the .net runtime and do not see a clear reason why it crashes. I'll post the relevant functions later.

[MagicRB]

I know, it tries to notify the user that they should update their graphics drivers. That's why it tries to report something. But still, it does work in wine-staging, so we still need to find the relevant patch.

[MagicRB]

Can someone help? I'm not sure what to look for in those patches.

[MagicRB]

https://stackoverflow.com/questions/11796082/invalid-parameter-when-setting-an-image and this seems to be related, I'm not any closer to figuring this out tho.

[MagicRB]

line 914 seems to be the problem, that's the only thing that i can see, the GdiPlus.dll is a wine native dll as can be seen here

[MagicRB]

GetGdiImageFlags returns invalid parameter if image or flags are empty, as can be seen here, line 5219, so it's probably getting nullified either somewhere in .net or when being passed to the native library from wine.

[MagicRB]

I think I found it, if I'm understanding this correctly,

GpStatus WINGDIPAPI GdipGetImageFlags(GpImage *image, UINT *flags)
{
    TRACE("%p %p\n", image, flags);

    if(!image || !flags)
        return InvalidParameter;

    *flags = image->flags;

    return Ok;
}

this function should not check if flags is 0, as flags is the output variable, which can be whatever.

[MagicRB]

I am completely wrong in my last comment, I hate pointers. Anyways, I'm going back up the stacktrace trying to find out why image is null.

[SpookySkeletons]

I am not sure on the legal ramifications but Space Engineers provides a visible/ open EULA of their source code on github, if you can look through, so you don't have to decompile. Might be worth a look through if it's kosher, to figure out what is blowing up and commit to wine.

https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/EULA.txt

Edit: They do have an intertoperability clause which wine falls under as 'compatibility'

[aaronfranke]

Please wait a few months until Valve updates the version of Wine that Proton uses. Valve has some patches on top of Wine and needs to test for stability, so there are reasons that Valve does not immediately update the version of Wine that Proton uses.

@SpookySkeletons That source code has not been updated since 2016.

[SpookySkeletons]

@aaronfranke This affects Vanilla wine as well as Proton, whichever arrives first can upstream it to the other. Space Engineers has been a major pain for years in any sort of wrapper, even when it did work it was stable as a two legged stool.

Perhaps I just don't know how any of this works but this might be something to look into.

6421.401:0031:0032:trace:module:load_dll Loaded module L"C:\windows\assembly\NativeImages_v4.0.30319_64\mscorlib\386b8793866138dad77588a7399d11c3\mscorlib.ni.dll" (native) at 0x64478000000 The library loads up at 0x64478000000 Some kind of function turns and burns here, sharing a very close trailing memory space with mscorlib.ni.dll:

6421.486:0031:0032:trace:seh:RtlVirtualUnwind type 0 rip 64478454d69 rsp 53b5d0 6421.486:0031:0032:trace:seh:dump_unwind_info **** func 454cf0-454da3 6421.486:0031:0032:trace:seh:dump_unwind_info unwind info at 0x644785364bc flags 3 prolog 0x10 bytes function 0x64478454cf0-0x64478454da3 6421.486:0031:0032:trace:seh:dump_unwind_info 0x10: subq $0x68,%rsp 6421.486:0031:0032:trace:seh:dump_unwind_info 0xc: pushq %rbx 6421.486:0031:0032:trace:seh:dump_unwind_info 0xb: pushq %rsi 6421.486:0031:0032:trace:seh:dump_unwind_info 0xa: pushq %rdi 6421.486:0031:0032:trace:seh:dump_unwind_info 0x9: pushq %r12 6421.486:0031:0032:trace:seh:dump_unwind_info 0x7: pushq %r13 6421.486:0031:0032:trace:seh:dump_unwind_info 0x5: pushq %r14 6421.486:0031:0032:trace:seh:dump_unwind_info 0x3: pushq %r15 6421.486:0031:0032:trace:seh:dump_unwind_info 0x1: pushq %rbp 6421.486:0031:0032:trace:seh:dump_unwind_info handler 0x644783da000 data at 0x644785364d8

[Guy1524]

It looks like mscorlib.ni.dll is a component for the .NET framework, which is known for being unstable under wine. You might have luck using winetricks to fiddle around with dotnet, but hopefully Ethan Lee will devise a better solution in the future.

[FurretUber]

With Mesa 18.3.1 with patches applied from here applied to support Transform Feedback and using winetricks to install .NET 4.7.2 I got very close of having the game working using DXVK. The game reached the main menu, running at 120 FPS, and the mouse cursor loads. However, the game crashes before the background video and the menu buttons appear.

The log messages seem to be pretty relevant on this case. The DXVK warn seems closely related to what happened with Wine:

SpaceEngineers_dxgi.log

SpaceEngineers_d3d11.log

steam-244850.log.gz

SpaceEngineers.log

VRageRender-DirectX11.log

My system information. Please note this is showing a different Mesa version because the 32-bit and the 64-bit Mesa builds are distinct right now.

[MagicRB]

I've managed to get to gameplay with wine-staging, dxvk, proprietary nvidia drivers. All voxels were horribly malformed and i haven't managed to reproduce it since wine updated.

[SpookySkeletons]

@FurretUber The latest version of the game locks up after a minute or more. Opt down to the multiplayer overhaul in the beta tab and it will work.

[steve7233]

I just upgraded my GC to NVIDIA GeForce GTX 1060 and all my steam games work via steamplay except SE. I press play and SE tries to start then stops. No error message, no sound, and no game window. I have tried all the proton versions that steamplay will run. After reading this thread I at least know that many people are trying to figure it out. Sounds like a new version of proton and wine are needed. I was hoping I could use wintricks or something but it might be more complicated. That's a bummer. Maybe a lib or several libs with winecfg?

[Maltahl]

This game can launch with wine 4.3 and DXVK 1.0 - But you will need .NET 4.7.2 as additional installation. Lutris installer for the game works flawlessly for new installations. If you have a current installation of space engineer it might not work, i have yet to figure out why that is the case. After that you can play the game but minor errors will still be there such as:

• Crashing when you fly crafts into other crafts or rocks at 20+m/s (report tool for SE appears)
• After splash screen you have to click the mouse a couple of times to get to the main menu since the cinematic wont play else you just have a black screen.
• Minor audio stutters which was mostly fixed with wine 4.3 but will get better as faudio gets futher development.
• Slow loading screens in the beginning due to new shaders need to be cached.

Pastebin here of logs when running and crashing into a planet that crashes the game. https://pastebin.com/tPC8y3tK

[jarrard]

I take it that the latest proton beta isn't wine4.3 yet? which is why it won't work via steam directly?

[FurretUber]

I managed to make Space Engineers working. It is definitively not on a good shape, but it works. I had to:

1) Install dotnet472 on Space Engineers WINEPREFIX; 2) Build FAudio with xWMA support and libraries on non-default directories. This FAudio build must work with Megadimension Neptunia VIIR; 3) Make the built libFAudio.so be used for Space Engineers, be replacing the Proton one from lib64 or LD_PRELOAD; 4) Make sure video drivers support Transform Feedback, as Mesa 19.1.0-devel for Intel Gen9; 5) Be sure the built FAudio library built WILL NOT work! It can't find the needed libraries when starting Space Engineers; 6) Space Engineers should work but with no sound.

There are a few bugs related to graphics as opening video that does not load, on edges that effect because of helmet is buggy, even then it is great considering the GPU is an Intel HD Graphics 520 and had bugs on Windows 10 until very recently.

A lot of bugs regarding terrain generation are happening, all planets and moons are hellish landscapes.

Images:

[jarrard]

I sort of got it working but fps was real slow at menu (never bothered to play) and audio is crackling. I used https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install correctly.

EDIT: Didn't install faudio this time around, and no sound so I must have installed it correctly. Perhaps the main menu just does that because it works but as you point out, the terrain generation is completely messed up.

[Maltahl]

If you install via Lutris ( yeah i know ) It has a tkg build of Wine 4.4 with F-Audio that works wonders.

On Wed, Mar 20, 2019 at 3:25 AM jarrard notifications@github.com wrote:

I sort of got it working but fps was real slow at menu (never bothered to play) and audio is crackling. I used https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install correctly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-474658732, or mute the thread https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi .

[MagicRB]

I'll try and report my findings, it's a shame you can't download wine builds from lutris, without lutris

On Sun, Mar 24, 2019, 15:09 Maltahl notifications@github.com wrote:

If you install via Lutris ( yeah i know ) It has a tkg build of Wine 4.4 with F-Audio that works wonders.

On Wed, Mar 20, 2019 at 3:25 AM jarrard notifications@github.com wrote:

I sort of got it working but fps was real slow at menu (never bothered to play) and audio is crackling. I used https://github.com/Kron4ek/FAudio-Builds but perhaps it failed to install correctly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-474658732 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-475963063, or mute the thread https://github.com/notifications/unsubscribe-auth/AHonVxCEiLofIF2Jsbrz-HZMdIWpKfgyks5vZ4c2gaJpZM4XyGNi .

[jarrard]

Copied wine4.4 faudio protonified into my custom steam compat folder, reinstalled game and dotnet472, loaded up, no audio. Game looks like it might run better but it has this stuttering going on, maybe the non functional audio is to blame. Anyway didn't seem to fix my audio issue, probably need to install precompiled bins from somewhere into the custom proton folder, I'm on arch so likely ones compiled on other distros won't work.

EDIT: I built custom faudio with ffmpeg support, still no luck with sound, probably doing something wrong, shrug. Anyway game is unplayable IMO, all planet bases maps don't work/broken, has stuttering & crashing.. Maybe one day.

[MagicRB]

I doubt that bins from other distros wont work. They will, just install wine the arch way to get all the dependencies and that should do it.

On Sun, Mar 24, 2019, 23:59 jarrard notifications@github.com wrote:

Copied wine4.4 faudio protonified into my custom steam compat folder, reinstalled game and dotnet472, loaded up, no audio. Game looks like it might run better but it has this stuttering going on, maybe the non functional audio is to blame. Anyway didn't seem to fix my audio issue, probably need to install precompiled bins from somewhere into the custom proton folder, I'm on arch so likely ones compiled on other distros won't work.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476010132, or mute the thread https://github.com/notifications/unsubscribe-auth/AHonV0PNKjPrMbFLzUDFBzbXqp2ZjOUNks5vaANBgaJpZM4XyGNi .

[jarrard]

Yeah it's just a install issue at my end, I also seem to only be able to build 64bit libs, can't see the 32bit ones unless their the same file (no idea).

When I copied my libFAudio.so file to the proton_wine custom folder and loaded SE it just set all my volume settings to zero, and would not save them if raises so something is a miss.

BUT like I said, the game has major issues under Linux, so not like I could realistically play atm unless its pure space survival with no moons or planets!

[MagicRB]

The main problem is terrain generation. I'm puzzled as to how such hellish landscapes can be created

On Mon, Mar 25, 2019, 06:51 jarrard notifications@github.com wrote:

Yeah it's just a install issue at my end, I also seem to only be able to build 64bit libs, can't see the 32bit ones unless their the same file (no idea).

When I copied my libFAudio.so file to the proton_wine custom folder and loaded SE it just set all my volume settings to zero, and would not save them if raises so something is a miss.

BUT like I said, the game has major issues atm so not like I could realistically play atm unless its pure space survival with no moons or planets!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476063606, or mute the thread https://github.com/notifications/unsubscribe-auth/AHonVxB8URy1FGMFsPoU2eRKq1dVFeg6ks5vaGP8gaJpZM4XyGNi .

[jarrard]

Yeah if someone can figure that out it be great,. What I'm thinking is the game is detecting maybe limited memory or limited cpu cores hence it can't do the job.

If you look in the in-game error log it says the terrain is too complex etc in those instances, check it out.

[MagicRB]

yeah, wine with reporting available memory, cores, and stuff isn't great.

On Mon, Mar 25, 2019 at 6:55 AM jarrard notifications@github.com wrote:

Yeah if someone can figure that out it be great,. What I'm thinking is the game is detecting maybe limited memory or limited cpu cores hence it can't do the job.

If you look in the in-game error log it says the terrain is too complex etc in those instances, check it out.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476064274, or mute the thread https://github.com/notifications/unsubscribe-auth/AHonV9U7V6QwDB69qwGpkGR_avGmUh7Jks5vaGTdgaJpZM4XyGNi .

[fazo96]

I have a i7 4790k, 16 GB of RAM and GTX 1080. The game runs using the lutris script with wine 4.4, FAudio and DXVK and performance is good, 1440p@60FPS however:

• planet maps don't work neither in single or multiplayer
• music is absent
• there is a periodic, very regular stuttering while playing that is very annoying
• the game freezes 30-60 minutes into play, seemingly at random, and then crashes

I don't think it's playable at this stage

[Linux74656]

I may have found out why the terrain is generated improperly. It appears that the heightmaps used by the game are not being read properly by the game or wine/proton or something… I got the terrain to generate on the Alien Planet by opening the terrain heightmaps( the files named front.png back.png left.png right.png up.png down.png Located at ~/SpaceEngineers/Content/Data/PlanetDataFiles/Alien/) and without modifying the actual image saved them with new options. I used Gimp version 2.10.6 to overwrite the files with the following Options.

Strangely when using the spectator cam to go to the local moon(which I did not apply the fix to) the game just froze instead of generating the spiking terrain. The Following are screenshots from the working game:

My knowledge about this is very limited, so if someone could figure out what is going on here it would be much appreciated.

Note: My game constantly crashed while trying these fixes, but the times I was able to get into the game did not crash during the play session, with the exception of when I went to the moon and the game froze. After that I could not get the game to load the save game or start a new world without a lockup. Once I deleted and recreated the prefix the game started working again.

[jarrard]

Very nice trouble shooting there. So we need proton/wine to look into why it can't read these PNG files correctly. Could be related to a nasty bug in wine itself not being able to read specific settings for those files!

I wish this could be bumped to a dev to be looked into, really would love this game to work better. The height-map issue is not the only problem sadly, we have sound stutter and frame stutter to deal with next, but that could be partially related.

[SpookySkeletons]

@Linux74656 How could the png stuff possibly interpret the png wrong?

That would explain the crazy high-low thing going on... Perhaps it's just being truncated from 16 to an 8 bit int...

What happens with 8bpc vs 16 bpc & compression off vs max compression?

Might be worth asking for a quick fix from the KSH devs as this doesn't seem to impact the base game any by making this tweak. However it will be worth fixing this in upstream wine now that we know the issue.

Most importantly for his fix what png lib does wine use?

[Linux74656]

I am not sure what png lib wine uses, but if you install MS Windows Imaging Component (windowscodecs) with winetricks into the games prefix; most of the games images(icons, thumbnails... etc) are pink and the terrain renders completely flat.

I tried the suggestion from @SpookySkeletons Attached are images from the compressed 8bpc GRAY and 16bpc Gray (Uncompressed as compressed made no difference in either case). It appears that the 16bpc is performing in a similar way to the original images provided with the game.

Strangely when testing the 16bpc Gray(both compressed and not compressed) the game would not start the Alien Planet scenario, it kept freezing while loading. I got around this by starting and Empty World scenario in creative mode and spawning the planet. After this I decided to compare the original file to the modified ones. I used a tool called tweakpng (windows only but runs in wine without issue) to look at the header data of both the png provided with the game and the one I modified with 8bpc. The file that comes with space engineers does indeed use 16bcp grayscale. While the modified one, as expected, uses 8bcp grayscale.

I think they(Keen Software House) are using 16bcp because it would allow for more gray scale color depth and perhaps provide smoother terrain, although without being able to test 16bcp terrain generation in the game i can not say for certain.

[jarrard]

So does the game load up with just WINED3D (dxvk disabled) and does it read 16bcp terrain correctly then? If that can't be done then perhaps DXVK can be tested under windows10 to see if it's the culprit or if Wine itself is to blame.

Its important to know if DXVK or WINE team should get the bug report.

[Linux74656]

The game crashes when using DirectX(PROTON_USE_WINED3D=1) with an error message.

When i click on the empty box before clicking on the error message, i can hear the Space Engineers main menu music and the button sound.

If someone can get DXVK to run this game in Windows that would be great. In the mean time i will continue to try to get PROTON_USE_WINED3D=1 to return positive results.

[jarrard]

Try spoofing to AMD custom settings flag which I think is possible with wines regedit or variables somewhere using vendor and product ids. There are a few tricks that can be done. (I can't remember them off hand atm)

[SpookySkeletons]

I think Keen chose 16 bit specifically to fit the height gradient as closely to the 2048x2048 image as possible, compared to the 256 gradations of 8 bit.

I'm not seeing any lack of precision in the height mapping though by using this workaround... Perhaps the engine itself expects a downsample from 16 to 8 in the first place or one is implicitly applied that causes this in the first place. Keen seems to be applying precision in excess to a process which throws out the extra precision.

Either way if we could get in contact with keen and ask if it's a good idea to ship 8 bit heightmaps it might make for a nice band-aid for inching toward proton support. And very definitely upstream a real fix for Proton as this is an issue with wine itself...

[Linux74656]

@jarrard I tried setting the card to an AMD RX480 VideoPciDeviceID to 10de(hex) and the VideoPciVendorID to 1002(hex) and still got the same error. I was however able to start the game by running the SpaceEngineers.exe with wine 4.5 and d3d11_43 installed. The game got to the main menu but, it locks up when trying to load a scenario.

@SpookySkeletons I will send an Email to Keen support, with a link to this thread and see if i get a useful response. Maybe we will get lucky and they will look into it.

In the mean time i will keep trying to get Space Engineers to run with d3d11.

[Linux74656]

I got WINED3D to work but not through steam or proton. I deleted the old prefix and created a new one with steam. I then installed the entire dx11 redist from Microsoft, as well as the usual dotnet472 and xact. I also had to force Space Engineers to run in windowed mode as it was constantly freezing and crashing otherwise. I was able to get past the loading freeze by starting a new empty world instead of straight onto the Alien planet. I used the spawn menu to add the alien planet in for both worlds.(Results in pictures below)

The 16bpc did not work in WINED3D, and the 8bpc still did.

EDIT: I was looking at WineHQ for similar issues, when i stumbled across this bug report: https://bugs.winehq.org/show_bug.cgi?id=46558 Comment 8 References this thread, and the temporary fix, so they are definitely aware of what is going on. Let's hope they can figure it out! :smile:

[Linux74656]

As for the stuttering issue I have been trying various things to see if i can narrow it down. The stuttering issue exist in both WINED3D and in DXVK (I noticed DXVK uses fewer CPU resources compared to wines D3D implementation). And the issue seems to take place at the same intervals no matter what graphics settings I use.

I have tried various CPU settings with the following results. I set my cpu(i7 4770k) to only start with one core(used bios to disable all but one core and no hyper-threading). The game took longer to load but once in the world, the stuttering seemed unaffected.

I then underclocked (4.2Ghz is what i usually run it at) my cpu to 2.5Ghz (with all cores and hyper-threading re-enabled). The stutter still happened at the same same interval, but the duration of the stutter was noticeably worse, rather than the stutter lasting a fraction of a second, it seemed to last a second or more.

So I then overclocked my cpu to 4.5Ghz and the stutter still took place at the same interval, but was marginally less noticeable than the 4.2Ghz speeds it normally runs at.

So could this be a game update thread issue? Is the game performing calculations at set intervals and overwhelming the cpu? If so what would cause this to be noticeable on Linux/wine/proton, compared to unnoticeable on windows?

I contacted Keen support and told them about the issues we are experiencing. I gave them the three main problems to getting this working on Linux (the terrain, the stutter, and the audio), and explained what the issue is with the terrain. I also linked them this thread. They responded with something along the lines of they are keeping an eye on Linux, but are not planning any changes at the moment.I think for the mean time we are on our own.

[jarrard]

Maybe you can record a apitrace and post it over at the DXVK forum? might still be fixable at DXVK's end you think?

[Linux74656]

OK i opened an issue and referenced this thread.

UPDATE: It is not DXVK causing the issue. Which means our problem is most likely not related to the graphics.

[Linux74656]

Quick note for anyone wanting to get rid of the annoying black screen and, the need to click to get the game to start the main menu: you can rename(just add .old to the end of the file) the file here :~SpaceEngineers/Content/Videos/KSH.wmv and the game starts more normally. I even get some startup images when the game starts full screen.

[Linux74656]

Interesting development: Now that DXVK and graphics issues have been ruled out, i have turned my focus to the audio. And I think I may be onto something.

If you convert the main menu music (~/SpaceEngineers/Content/Audio/MUS/se_mainmenu1.xwm) to an mp3 format(but make sure the file name and extension are the same as the original, IE se_mainmenu1.xwm) then there is no lag in the main menu, although the music does not play. If you simply delete the file the lag in the menu still exist and the does not play. So if you give the game engine a sound file type it can not recognize it seems the menu lag issue is solved.

I tried to see if this fixed the stutter in game, but when I convert the other music the same way, the game enters an infinite loading loop when trying to start a game. I also tried disabling sound in wine and in the game, but that had no affect in either case.

If you open the original se_mainmenu1.xwm in VLC, the same kind of stutter happens as in the game.

[jarrard]

isn't XWM files some crappy microsoft file format?

Yeah fallout4/skyrim, all the games that have had issues in the past with audio used this format of xaudio2.