I wish all game executables would be OS agnostic, something similar to WebAssembly: GameAssembly. For example you can no longer play 32-bit games on new macOS version, neither 32-bit Windows games under Wine. It's almost impossible to find 64-bit .exe files so they can run under fine under Wine/Crossover.
The code running on the CPU is arguably the smaller problem when it comes to games: At least for consoles, they're often depending on very low-level GPU implementation details, especially for older titles and platform exclusives.
Older consoles had even more dedicated chips doing relevant stuff other than "simple" I/O, like e.g. the SNES's sound chip, which was a completely independent CPU running its own little programs in parallel with the CPU and GPU.
Of course you could "mandate" a high-level VM for all future game development, but given the static nature of console hardware specs, that wouldn't be competitive for titles wanting to make use of cutting-edge graphics.
It is not enough to provide portable machine code to make games portable, there are lot of different APIs that games need: graphics API, windows API, input API, sound API, disk API and so on. Sometimes they need kernel modules for anti-cheat and anti-piracy features.
What saddens me is that open-source OSes do not want to provide a common set of APIs so that the developer only has to write and test the code once and it works everywhere. There is flatpak, but as I understand, it doesn't provide a set of APIs, it simply packs a Linux distribution into a virtual machine without any specifications or documentation. So ugly, and no compatibility for smaller non-Linux OSes.
I was able to run 32-bit Windows games in Wine on Mac, even on Apple Silicon. GTA IV on my M1 mini. There's some kind of "32 on 64" emulation built into whatever version of the 32-bit Wine that PlayOnMac installs. Impossible to Google so idk how it really works.
It's funny how the Mac is more compatible with old Windows programs than old Mac programs.
Old windows programs had the luck that intel fucked up Itanium, which left us with AMDs idea to just take the existing 16 bit compatible 32 bit processor and turn it into a 32 bit compatible 64 bit processor (that might also be 16 bit compatible, not sure on that one). As result new and old windows programs use a lot of the same basic instructs and emulating the newer programs includes a lot of the work needed to also emulate the older ones.
Modern x86-64 processors are still capable of running 16-bit code but, assuming you want to do it from within a modern operating system, it needs to be 16-bit protected-mode code, which isn't that useful since I think most 16-bit games run in real mode. Hence why DOSbox/Bochs are used instead (also, for emulating the original sound/graphics hardware).
AFAIK, no 64-bit version of Windows ever shipped with native 16-bit support, though. That means 16-bit support on x86-64 in practice was only ever usable on a 32-bit operating system, which means you still couldn't have 64-bit, 32-bit, and 16-bit code running side-by-side, even if the hardware could theoretically support it.
The JVM does this pretty well for Minecraft. I doubt Minecraft would support Linux, the BSDs, etc without it. Bedrock edition (the not-JVM version which supports Windows and consoles/phones) doesn't even support MacOS even though it obviously could.
If Minecraft were a Microsoft product from the start, they probably wouldn't have made the Java version compatible with Mac or Linux (even though it uses JVM, there are some natives included), or wouldn't have made a Java version to begin with.
Also it’s pretty ironic that Microsoft, who wants to convince the entire world that c#/netcore is the next multi-os platform isn’t capable of delivering anything else than Minecraft Java on Linux.
It’s a shame that I can’t play with my son from my Linux PC since he plays on switch (so the c#/bedrock edition)
If it were, targeting all platforms would have been fairly easy (assuming it would still rely on OpenGL), sometimes just specifying RID e.g. `linux-arm64`.
They could target Linux fine with their C++ code, they actually have secret builds for Linux for Marketplace creators (they have been leaked occasionally) but they don’t allow the general public to use them
There is an unofficial Linux launcher that can run the Android build
No it doesn’t. It’s a UWP app with DRMs everywhere.
Although there is an unofficial Linux launcher capable of running Bedrock natively using the embedded machine code in the Android version but it requires to buy the game one more time from the Google play store.
.NET would probably be as close as you can get given it allows you to have portable assemblies with pointers, structs and simd code which is very relevant to games.
It models statically-typed compiled languages in a much superior way to WASM, there are projects showcasing how well e.g. Rust maps to it[0], and C++/CLI existed for a long time (although it's not cross-platform, and is considered cursed).
C and C++ could be mapped in a perfect manner to IL and then AOT compiled in ways that GraalVM's Truffle can only dream of (given that .NET exposes a very wide set of intrinsics allowing a lot of code to be ported that way).
Wine (+ Steam's Proton) works incredibly well these days, a huge improvement from the old days when barely anything ran, and what did run required heavy tweaking or even custom compilation.
On Linux, my Steam library of about 300 games runs almost in its entirety without issues (except for Last Epoch).
