The only way to have a gaming VM is to have a second GPU that you pass through to the virtual machine. That way the VM has good graphics performance. And as long as you have a modern CPU with virtualization features enabled, the relative CPU performance will also be good. So the way you would build a gaming VM is to have a desktop computer and put 2 GPUs into it. There’s no real way to make a good gaming VM on a laptop.
There are some ways to split one physical GPU so that it allows access from the VM, but I’ve heard that that is very hard to do, still has many pitfalls, and the end result performance still isn’t perfect (like it is with 2 GPUs).
My understanding was that they just translate the Proton result from running on x86_64 to ARM.
This sounds exactly like I was imagining: Doom 2016 runs perfectly well with Proton on normal desktop Linux, and then we add in the Box 64 translation layer into the mix so that ARM CPU-powered Linux systems can also run it.
Deathwake
(i nuked zenzone and will never let him forget it)
25
I don’t really know if this is how it still works, but I’m pretty sure a lot of windows gaming laptops use integrated graphics until you start doing something demanding, so you could give your gaming vm control over the gpu and leave your main os stuck with integrated graphics but that would probably mean replacing whatever utility decides when to activate your dedicated graphics. (Come to think of it, I have integrated graphics and dedicated graphics in my PC, and I have some virtual machine experience, might give it a shot.)
something about that is incompatible, not really sure how, it just sounds slow, not incompatible.
Ah yeah, that could be possible. But then on the host you are really limited to just like really light tasks, and like you said there could be some power management etc. problems related to that.
I’m like 99% sure Box64 people aren’t making their own Windows compatibility layer, because that would be insane as Wine has been worked on for decades and it still isn’t fully compatible. This is why the only sensible solution is to stack the compatibility layers to first make a game run on Linux x86_64 and then make the Linux x86_64 result work on an ARM CPU.
Good news everyone! Thrive 0.8.0 will mark a return of the Mac builds. Though again these won’t be “officially” supported and the workaround for running unsigned software still needs to be used on Mac. Maybe next year if there aren’t any too bad Mac-only bugs and we continue getting the wishlists the builds can be bumped up to official status.
On Saturday when the public test build for 0.8.0 goes live that will include the Mac version as well (hoping the Launcher actually works correctly on Mac still), but here’s already a test build for Mac to test now: https://dev.revolutionarygamesstudio.com/api/v1/download/120603 Note that the test build again requires jumping through hoops to run it as we still can’t sign them.
It took a bit over a day to get things running through the Godot Editor, mainly because I had to update all the stuff on my Mac and then tweak things here and there to get the native libs build working and Thrive looking in the right place for the results. That was relatively easy but then it took a further 3 days to get an exported build working because the load paths needed to be adjusted and the way libraries are handled on mac are a lot different (combining arm64 and x86_64 binaries into single lib files and extracting their symbols, which required full XCode to compile Breakpad which in turn meant that I had to update to one version newer macOS which took over an hour). Then the final hurdle was getting everything signed so that macOS would allow the game to run in the first place (it still requires holding shift to get the option to allow the program to run) as if things are inconsistently signed macOS will just say the app is corrupted or maliciously modified, so that took another good few hours messing with unzipping, signing stuff and re-zipping everything back up for distributing.
So in total it took 4 days to get working. Maybe surprisingly to some, but not really to me as I’ve seen how good Godot’s cross platform stuff is, there weren’t any mac specific bugs that appeared and needed fixing. I did see just one problem with a crash when initially going to the editor but I have no clue how I would fix that as the crash was in the graphics driver side, and I think shader caching or something makes it so that the same issue doesn’t trigger on my mac anymore.