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)
working:
vvvvvv (few slowdown in some areas, nothing frustrating) : Let’s Play VVVVVV
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)
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
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
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
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!
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
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 :
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 This game is HEAVY, and makes most handled suffer with native version, so an emulated version … I’ll try anyway !
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.
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
