Let's play x86 games!

Hello everyone,

For some time now, ptitSeb have been busy working on an x86 emulator for arm devices (mostly the open pandora and the Odroid), and more recently, he started working on a dynarec (x86 => arm).

What this mean is : we can play some linux x86 games on our gameshell !
You can compile it yourself using this repository : Github repository (ptitSeb was kind enough to let me add gameshell build instruction and config file to his repository, and that makes our life quite easier, as you can just use the flags -DGAMESHELL=1 -DARM_DYNAREC=1), or use my build : Google drive link

usage is simple : find your game’s main binary, and call it using box86.
for example, using vvvvvv :
<in vvvvvv folder>
box86 ./x86/vvvvvv.x86

Often, games will ask you for a few libraries, most likely libstdc++ and libgcc, here they are :
Google drive link (libraries)

Minor issues :

  • Undertale : weird graphics at times, GS resolution is a bit too low for some text/elements, keymapping needs to be changed (didn’t come up with a method yet). It is still playable as far as I got (which is not very far yet)

Important issues :

Not working :

  • Super meat boy (kinda slow, keymap is basically required, graphic issues due to low resolution)
  • Crypt of the necrodancer. Shame because this probably would be awesome on the gameshell.
  • Shovel knight. Could be an issue on my side though since apparently some people got it to work on other devices

If you test something, I will be happy to report the results in this post !


Why not using qemu user?

They seems to do basically the same thing, but I would expect qemu to better the x86 ISA as it is more supported overall, but I may have missed what box86 do different from qemu user?

I’ve beeing using it a lot on the other way, running ARM binary on x86

1 Like

Given the specifics of this project, I expect it to be faster for games than qemu, since it provides us with a dynarec, and also binds a few libraries to their native counterparts (for example, sdl2 calls will use the native libsdl2 library).
qemu user already parts with the kernel and syscall emulation, giving a huge speed advantage compared to traditional VMs (along with not having to emulate the full hardware), this project tries to go further by not emulating ressource-heavy libraries, which should be faster.

Also, the gameshell kernel was apparently built without binfmt_misc, which makes having an x86 chroot a total pain. box86 doesn’t need that (it’s also lighter thanks to this).

However I agree that this approach is bound to be way less flexible and compatible than qemu, at least for the time being. It’s also the approach being taken by the wine team with their hangover project, however their primary target is only arm64/x86_64 for the time being. It would also require a compatible kernel for the wine part.

qemu-user could still be interesting though, I will try to test it when I have a bit of time

1 Like

In theory, the bimfmt is only useful if you want to run foreign executable without knowing, you can do a

qemu-arch-static /path/to/exec

That’s basically what bimfmt is doing in reality.

But fair :slight_smile:

Yes, but qemu doesn’t do well with dynamically linked libs, for which the easiest way is to use a chroot.
And debootstrap wants the kernel to know how to run the binary files it uses.
There are probably other ways to do this, but binfmt seems like the easiest solution. I’m currently trying to compile a kernel with this feature enabled.

But yeah I other than stability I don’t expect QEmu to provide any performance benefits unfortunately :frowning:

I don’t expect either to be honest, I was just surprised that someone basically did the same as what qemu was already doing for quite a while. That does not mean that it is bad though!

Where should someone look for games to try ?
Other than vvvvvv

Well, since most free linux games are open sourced, that leaves as a main source paid software, and since DRM mess everything up, the best places to find games to test would be your gog and humble bundle library (that’s where it took mine at least). Some steam games are also available on linux and don’t have DRM bundled, but that really remain an exception more than a rule.

At this point, I would really not advise you to buy a game there if you only want to test it on the gameshell, as I don’t expect a lot of games to run.
However, if you DO own a few games, please test them if you have the occasion :slight_smile:

ok. I also had a look on but most of them do not have a .x86, do I need to recompile them somehow or can I call it differently in box86?

If you have the possibility to recompile them, box86 is not the tool you need (in that case, you could just recompile it to armhf directly), and unfortunately, box86 does not support the amd64 architecture…
But please note that x86 binary file does not necessarily have filenames ending with .x86 ! most of them does not have any indication, but you can use the file command to identify them.
Example of the output for a proper x86 file :

file x86/vvvvvv.x86
x86/vvvvvv.x86: ELF 32-bit LSB executable, Intel 80386,...

Example for a x86_64, not compatible :

file x86_64/vvvvvv.x86_64
x86_64/vvvvvv.x86_64: ELF 64-bit LSB executable, x86-64,...

Most godot games I found were compiled for x86_64, but I think there is another way to run those.

yeah… I tried a couple from itch but did not managed to make them load. I’ll wait and see if others find some other games…

It would be nice to run The Binding of Isaac…

First one is built in flash flash, shouldn’t be too hard to port, but I stopped because it asked for soooooo many libs … (and too lazy to check with the swf version now)
Rebirth I’ll try soon, but I don’t think performance will be good :frowning: This game is HEAVY, and makes most handled suffer with native version, so an emulated version … I’ll try anyway !

Hi man !

Thank you for this news.

Is there a chance this x86 emulator could works with Zelda Classic ?

1 Like

Maybe, but if the resolution is not 320x240, you will run into problems…

And why bothering with an emulator when Zelda Classic is opensource, so could be build as a native app for the ClockworkPi?

It may not compile stray forward, but better than using an x86 build.

1 Like

Hi Godzil !

Simply because the source are NOT compatible with ARM :slight_smile:

That’s a lie. The only reason they give is “allegro is not compatible” which is another lie. They just don’t want to spend time trying to build for arm.

Really ?

I’m not experiment in compiling. Could you help me ?

I don’t have lots of time to look at that at the moment, but it’s in my todo list to make it to build for arm / game shell. But that still don’t resolve the potential issue with the resolution. I know the default is 640x480 and can be changed but that does not mean it would work with 320x240

1 Like

I will try this, didn’t know about it :slight_smile:

But I agree, building for arm would probably be a better solution.

1 Like

I would greatly appreciate to learn one thing or two about compilation.

I had some lessons on C compilation when I was at university but that’s a long time ago !

So, until you can get started, could you give me some leads? Or guide me on what should I start?

In any case, thank you very much!