Run natively on Apple Silicon #32
Comments
|
I think it's better to make sure that everything is compiled as a universal binary, did you try with an Arm-compatible Unity player along ? |
timkurvers
added
enhancement
|
@nonoche2 Interesting idea. -variant="macos_x64_nondevelopment_mono"
+variant="macos_x64arm64_nondevelopment_mono"This change produces a build that crashes for me in the same way that changing it to |
|
do you still get a mention of libRosettaRuntime in the crash report? if so, can you check what you get with the File terminal command on every dylib and binary inside the app bundle? |
|
I encountered the same segfault during the initial phases of the custom build, and couldn't really figure out how to get it to play nicely. Thanks for opening the issue, would be nice to get this to work 🤩 What's interesting is that it completely crashes |
|
I am not getting a crash report with this, here is what I could capture via Console |
|
The backtrace I get from |
|
@timkurvers I am able to successfully run that via iTerm on Sonoma Beta 3 and get this in the log file (to confirm, only change being the one posted above switching to |
|
how about launching the app from the terminal with the -force-metal argument? |
|
@nonoche2 With @diericx Thanks, that's interesting! Curious if Sonoma fixes this, or whether iTerm is more robust. Either way, you should get unobfuscated traces (so you can which functions/methods things are breaking in) by changing the variant from On second thought: I'm not entirely sure if running the binary directly from any terminal is reliable 🤔 |
|
Hmm... seems like this might be a dead end. I'm not sure we can get it to run natively without Metal support and I don't think we can get that without an updated build from IronGate. Edit: Someone suggested this on Reddit
|
|
Done some more digging, and it seems that OpenGL is actively disabled in the Apple Silicon / arm64 build of the Unity standalone player. This would also explain the
Future problem: OpenGL support for macOS will seemingly be removed in Unity 2023.1. Let's hope IronGate either port the game to Metal or they stay on an older version 😬 Leaving this issue open, hoping we find some workarounds. |
|
But aren't we using the older version Line 17 in 1ae3fce It sounds like OpenGL should still work, it is just deprecated. Is it only supported via translation through Rosetta? |
Yeah, I think that's correct. This opengl-explorer project runs just fine as arm64. So, I wonder if Unity decided to just not support OpenGL for the arm64 build, which is very odd. That said: while running Valheim arm64 with a debugger, I managed to force the OpenGL renderer (by hotpatching memory) and then the splashscreens render just fine. That seems to indicate that all the OpenGL functionality is still there in Here it's stuck on loading Steam: 
Bit unsure whether this hotpatching is feasible for the build script, and whether the newer |
|
Do you know if it is possible to force Vulkan rather than trying to get OpenGL working? I am running Valheim like so Using the master branch it seems to just use opengl no matter what. I tried again using the change I mentioned above (using unity |
From reverse engineering 
There is no mention of
My current theory is that the arm64-build is either broken, or is solely looking for Metal, ending up with |
|
Wow great work. I wonder where this I tried to update the minor version of Unity on a whim to test your bug theory but it naturally collided with the game data and wouldn't run. |
I previously played the game on Windows and that had a 'Select game version: Valheim or Valheim (Vulkan)' popup, so I would imagine that at least UnityPlayer for Windows has that flag implemented. Have opened #33 which should be able to build a universal build, but please use at your own risk! 😊 |
|
Closing this issue as the official macOS client is now available! 🥳 (see #104) The official client is universal, supporting both Apple Silicon as well as older Intel Macs. |
I am super curious to see if we can get Valheim running natively. It looks like it would require getting Unity and the Steamworks.Net and PlayFabParty plugins running natively.
Unity is as simple as changing the
variantvariable inbuild.shbut I think it is better to start with Steamworks.As of
1.52Steamworks SDK supports arm. The latest SDK (1.57) ships with an ARM compatiblesteam_api.bundle.It seems like a stretch but would be super cool if we could just swap the new build in.
As this dll is compiled for both intel and amd it seems like a great first step as we can get it running without leaving Rosetta 2. I have tried swapping it into the artifact from
build.shwithout changing anything else. I am effectively doing this below.And then updating
./build/Valheim.app/Contents/PlugIns/Steamworks.NET.txtto the following grabbing values from herehttps://github.com/rlabrecque/Steamworks.NET/blob/a3fe8091f7237eef3f38becc3faa29b2dc6f9ce9/com.rlabrecque.steamworks.net/Runtime/Version.cs#L16
This crashes very early with a segfault... which is strange to me.
https://gist.github.com/diericx/d704b0a478fda2121764d037c8e63a50
I am wondering if anyone wants to work with me on this as I'm pretty stumped.
The text was updated successfully, but these errors were encountered: