Slightly off-topic, but the author also made gl4es, a library that basically allows all kinds of OpenGL apps to run on modern devices. Shameless plug: gl4es is what allowed me to port Neverball to the browser.
Neverball was working in the original glshim project before ptitseb forked it to gl4es. (Not to discount the significant work he's put in since, including the ES2 backend)
My bad, I completely forgot they worked off of a fork.
Did you ever try Neverball with glshim, though? Why? I'm the current maintainer of Neverball, always very interested in Neverball-related stuff.
When I was working on the Emscripten port, I tried a bunch of GL-to-OpenGL ES libraries. There were a few. I might have tried glshim, but not sure anymore, that was a couple of years ago. gl4es was the only one that worked without any obvious visual glitches.
I don't think there's a GL2ES and GL3ES? Are you thinking about GLES 2 and GLES 3? Those are graphics APIs standardized by Khronos, being versions of OpenGL for Embedded Systems (OpenGL ES).
Talking about emulation/VMs, I have recently played with multipass (from canonical) to run ubuntu VMs on my Apple M1. It works like a charm! In the past I have tried VMware and Vagrant, and while they somehow work, I’m always running into issues. More recently I tried qemu, and I spent many days trying to figure out the correct set of command line parameters to run linux.
The bad thing about multipass is that it only runs Ubuntu VMs. The good thing (besides working out of the box) is that mutipass uses qemu behind the curtains, and as part of the logs multipass spits out, one can see the complete set of command line parameters that was used to spin up the VM (so that can be used as a blueprint to run other VMs besides Ubuntu)
> tried qemu, and spent many days trying to figure out the correct set of parameters
It's really not that hard, once you get used to it. Or, if you rather not spend that precious time, there is a GUI tool that would configure those parameters for you:
Bonus: once started with virt-manager, run "ps ax | grep qemu", et voila - you have your qemu parameters, ready to copy-paste, should you wish to run exact same VM later from a script, or something...
One issue with those "shortcuts" is that you'll end up with crazy arg strings consisting of 20+ cryptic parameters.
qemu actually has sane defaults, so it's not that hard to launch a VM, if you don't need all fancy features (chances you don't).
I'm not sure if it's really worth it to spend time reading qemu manuals. I did it and I'm using shell scripts to start VMs which is easier for me than learning another qemu wrapper. And I know that I'm using bare minimum which I like.
Box86 / Box64 is however not emulation or VM. It translates X86 and X86_64 cpu code to ARM code. If anything it's very close to what Rosetta2 does on Mac.
It’s also how I sadly learned that M1/M2 chips don’t support nested virtualization. So no WSL on Windows on Arm under Mac OS Ventura. At least I could never get it to work.
You are correct, no nested virt support on macOS or Asahi. The rumor is this could be coming eventually to Asahi on M2, and maybe a future macOS release - but until it actually does it's a pretty huge drawback of apple silicon that is rarely mentioned.
Am I missing something? I know of this limitation but I dont understand why would anyone need this. What's the goal or running Windows on Mac to run WSL on it?
We migrated from Vagrant/VirtualBox to Mutlipass and Mutagen.io for file sync. The only thing I miss is the private networking options of VirtualBox. So we pull the ip from Multipass and put it in etc/hosts for name registration.
It will work on a RPi4 but the limitations is going to be the quality of the Vulkan drivers, and the memory that can be allocated for graphics.
Also, a Rpi4 is going to be massively underpowered to run most games in any way.
A much better example is the Mini PC with a D2000 Phytium 8 cores ARM process from China, equipped with an AMD RX550 GPU - it can actually run Doom 2016 with Box86 and Box64: https://youtu.be/5JwflzpWDzk?t=614
Vulkan drivers on the RPi are kinda terrible. Only supports Vulkan 1.0. For better compatibility, a Rockchip SoC with Mali GPU and Panfrost drivers support desktop OpenGL 3.1, so you can use Wine's WineD3D on that.
ARM64 is interesting because a ton of people have ARM64 hardware. In an ideal world we'd all be using RISC-V rather than either ARM64 or x86_64, but we're a long, long way away from that.
ARM does indeed have benefits, but if the most notable ones to you are laptop hardware and screen quality then I'd argue that ARM doesn't really interest you at all.
Smartphones, tablets and ARM64 server deployments vastly outnumber these luxury segment consumer devices.
There is a much better business case for x86 binary translation outside of a lineup of laptops relatively few people own (despite the crowd having formidable purchasing power)
RISC-V may become the open source ARM, or it may be a complete bust. At this point, either could happen. As it is now, there are only a few hardware implementations and all of them are dog slow compared to ARM.
You keep repeating that the Arm isa has toxic or super-toxic IP. Are you implying that it can actively harm users of the Arm ISA or do you just object to anything with proprietary IP?
https://neverball.github.io