Stardew Valley on aarch64

Posted on 2020-01-15 by Nick Thomas

At the end of last year I got a Pinebook Pro - mostly for reasons of paranoia.

So far, it's been pretty good, but there was

one thing that I couldn't get working: Stardew Valley

You could call me a little bit addicted to this game, but it's proprietary,

closed-source, and the authors don't release binaries compiled for aarch64 -

although they do very kindly release x86_32 and x86_64 Linux binaries, which

is more than most companies do.

I left a message on the forum and moved on, confident that it wouldn't ever

happen. I vaguely knew it was written in C#, but it's not an ecosystem I have

any experience in. I figured it was going to be the kind of thing that comes

under "possible, but not trivial" - and aarch64 + linux is super-niche.

Fast forward a few weeks, I mentioned it in passing on the `#pinebook` IRC

channel, which went a little like:

They rather roundly assured me that it wasn't an issue at all, and literally

10 minutes later I had a working Stardew Valley setup. This is incredible.

I'm documenting the steps I took so I can come back to this in the future, but

maybe it'll be useful for others too.

First, you need a copy of the game. I was working with v1.4 as shipppd by

GOG Games. It comes as one of those `.sh` files that contains an archive. That

doesn't have aarch64 support, and doesn't run on the PBP. Fortunately, I'd

already installed it on an amd64 laptop so I just rsynced that over:

I'm sure it's possible to make it run, I'm just being lazy. I'll update this in

the future if I work out how to go from the `.sh` file.

What does this give us?:

The magic here is that not all the `.dll` and `.exe` files here are **Windows**

object files. Instead, many of them are just Mono bytecode, which is analogous

to JVM bytecode:

We need Mono to run these assemblies. I guess the `StardewValley.bin.*` files

ar just stripped-down Mono runtimes that invoke `StardewValley.exe`!

The `mcs.*` binaries are "Mono C Sharp" - I don't know C#, but I assume it's

another essential part of the runtime.

Debian has Mono + MCS already, so...

We can then try to run the game:

Amazingly, that's **almost sufficient**, all by itself, to get a fully working

game, at least for me. It starts up, and the only obviously broken thing is

sound. There are some complaints on the comamnd line that don't seem to get in

the way of actually playing it.

Wat.

No sound is annoying though, how about we fix that?

Turns out Stardew Valley only **requires** two external libraries: SDL and

libasound. I've no idea if the graphics is working even though it can't find

SDL, or if it can find my native SDL libary but not the libasound one, or what,

but it's trivial to fix. Edit `MonoGame.Framework.dll.config` and add these

two lines:

Now you just need to put those two .so files into that directory locally, and

sound begins to work!

(I just symlinked `/usr/lib/aarch64-linux-gnu` into place, which does the same

job).

At this point the game works perfectly, including LAN multiplayer - which is

ridiculous - and despite worries about endianness, it can load and run my saves

as well.

There are a few complaints on the console though. Let's see what we can do

about them.

OK, these are shipped with `mono-runtime` (actually in `libmono-system4.0-cil`)

anyway. The complaint is that these assemblies were compiled with a different

version of Mono, but it's falling back to the main ones anyway, so we can just

move these out of the way.

The only `System.*.dll` file we need to keep is `System.Runtime.Serialization.dll` -

the rest can be moved out of the way.

I am *astonished* that this one isn't a fatal error - but the game runs fine

even though it can't find an external library. Ridiculous.

Galaxy is GOG's multiplayer gubbins. If you've got a Steam game, it's different,

I'm sure, but the functionality this stuff is *for* is to negotiate multiplayer

games with strangers.

I have no use for this myself, but `libGalaxyCSharpGlue.so` is looked up via

another dllmap in `GalaxyCSharp.dll.config` - it's not packaged by Debian, and

it may even be proprietary GOG code, but if we can get an aarch64 version of it,

making it work should be as simple as adding an entry there.

If this did become a fatal error at some point, the minimum work would be a stub

implementation that meets the ABI but always says "no games available" or some

such.

And... that's all the errors. Despite a different architecture, despite being

short some libraries, and despite running reverse-engineered (Panfrost) graphics

drivers with only a bare whisper of OpenGL support, my favourite game is running

at normal speed on an architecture its authors and publishers didn't even think

about.

Again I say: ridiculous

...maybe I should learn some CSharp?

Pinebook Pro

Stardew Valley

Forum message

GOG Games: Stardew Valley

Questions? Comments? Criticisms? Contact the author by email: gemini@ur.gs

mailto:gemini@ur.gs