Box86 0.2.6 / Box64 0.1.8 Released With Working Steam & Steam Play On Non-x86 CPUs

[phoronix]

Phoronix: Box86 0.2.6 / Box64 0.1.8 Released With Working Steam & Steam Play On Non-x86 CPUs

Box86/Box64 is out with new versions today for this open-source project getting x86/x86_64 binaries running on other architectures like Arm and possibly RISC-V and more moving forward. Exciting with Box86 v0.2.6 and Box64 v0.1.8 is getting Steam and Steam Play working for at least the basics...

https://www.phoronix.com/scan.php?pa....6-Box64-0.1.8

[risho]

I tried using box when I was on an m1 mac inside of parallels but apparently box86 only works if your cpu supports 32 bit arm instructions. As best I can tell m1 doesn't support this so I couldn't really get it working. There is an alternative project out there called Fex which was easier for me to set up and supported x86 on arm 64.

[Developer12]

I tried using box when I was on an m1 mac inside of parallels but apparently box86 only works if your cpu supports 32 bit arm instructions. As best I can tell m1 doesn't support this so I couldn't really get it working. There is an alternative project out there called Fex which was easier for me to set up and supported x86 on arm 64.

You may have been missing 32 bit libraries. Pretty sure the CPU still supports 32 bit instructions just fine.

[Developer12]

Seems they also merged basic PowerPC and POWER9 LE support. https://github.com/ptitSeb/box86/pull/279

[blackiwid]

Generally speaking, I think this is good, yet I would suggest focusing more in getting around using steam as some sort of middle man thing for gaming in linux.

I mean even with openhmd and a opensource tool they often depend on steamvr, in windows it get's even more perverse when you start steam somehow linked or dependend on Microsoft Mixed Reality program just to start a steamvr game ore tool.

It's ok to use a library that a program depends on, but you don't want a programm to have another program run especially proprietary ones.

But even outside of VR, which this news is more about, I like that lutris assists people more to install easily stuff outside of steam. And I would rather have some sort of opensource Steam-replacement, that maybe optionally interopt with steam to buy stuff over it but not have games depend on steam.

I mean you can't force the developers to use this alternative things, but if opensource tools/programs start to use proprietary valve programs as dependencies... it get's very very strange to me.

A hmd is a slightly upgraded monitor why would I need to use a proprietary programm to use it... maybe went slightly OT, but hopefully it's still relevant.

[blackiwid]

Btw another thing, I don't like that game streaming is somehow included into this steam blob especially on the client side, so first I would suggest that valve opensources a streaming client, I don't see a real reason / advantage to have a streaming client proprietary only, because you have to buy the games in the game "server" pc.

So what the hell would be a good reason to make the client side proprietary? But the advantage would be great, you could isolate proprietary Software on one pc and then have completely clean from proprietary software clients (notebooks htpc...) and be able to play games without tainting this clients with tons of proprietary software.

But the next best thing without coorporation of valve would be gaminganywhere.org

[Developer12]

Generally speaking, I think this is good, yet I would suggest focusing more in getting around using steam as some sort of middle man thing for gaming in linux.

I mean even with openhmd and a opensource tool they often depend on steamvr, in windows it get's even more perverse when you start steam somehow linked or dependend on Microsoft Mixed Reality program just to start a steamvr game ore tool.

It's ok to use a library that a program depends on, but you don't want a programm to have another program run especially proprietary ones.

But even outside of VR, which this news is more about, I like that lutris assists people more to install easily stuff outside of steam. And I would rather have some sort of opensource Steam-replacement, that maybe optionally interopt with steam to buy stuff over it but not have games depend on steam.

I mean you can't force the developers to use this alternative things, but if opensource tools/programs start to use proprietary valve programs as dependencies... it get's very very strange to me.

A hmd is a slightly upgraded monitor why would I need to use a proprietary programm to use it... maybe went slightly OT, but hopefully it's still relevant.

The Steam storefront is where the games are. Everything else important (proton) is open source.

[blackiwid]

The Steam storefront is where the games are. Everything else important (proton) is open source.

Not all games / tools are there:
1. Here a Outer Wilds mod for VR:
https://awesomeopensource.com/projec...parta/nomai-vr

• Steam and SteamVR installed (even if you're using a non-Steam version of the game);

So you can get here the game outside of steam and the mod itself is installed in a mod manager also not inside of steam, yet it needs you to have steamvr installed to work.

2. https://git.dec05eba.com/vr-video-player/about/
Also requires steam(vr).
A small opensource tool that requires 1gb steam client to work... a abomination.

Is there even some sort of launcher VR tool, that is some sort of 3d desktop like a house or something that is available in Mixed reality launcher from MS or Steams house thing.

It would be nice to be able to use VR in linux without Steam I know there is some obscure tools with monado where you can use it professionally in blender and one other tool, but I talk more on the entertainment side.

[loganj]

so any arm socs that support discrete gpu? also any very low power dGPU (15-20w max) that can perform as good as a ryzen apu (to keep power consumption as a low as a laptop)

[dragon321]

You may have been missing 32 bit libraries. Pretty sure the CPU still supports 32 bit instructions just fine.

AFAIK no. M1 doesn't support 32 bit ARM instructions. It's simply not implemented and SoC is only capable of running 64 bit ARM code. Even with 32 bit libraries it won't be able to execute 32 bit code. Apple completely dropped 32 bit support in their operating systems so it wouldn't make any sense for them to support it in their SoC.