The same thing can be done for RISC-V.
Also there is not a way to translate xbox360 games and n64 games into C++ and then compile them for PC so they run natively. So the binary compatability thing isn’t an issue.
I personally have been daily driving a fully free and open source set of software on all my machines for years now, and I only really have issues with video drivers, and only then because I don’t want to switch to Wayland from X11. If RISC-V takes off and is viable as a desktop I will be able to run my exact same setup on it, the same way my raspberry pi can do anything my pc can. This is one of the perks of using open source, among many more. It’s a much better experience knowing that you and the community can solve any problem with a little bit of elbow grease, rather than being trapped by proprietary code with no way out. It literally feels freeing, I can’t really explain it.
I’m a bit out of the loop in the emulation scene. But the last time I was really involved, dynarec proved trickier than expected. I have my doubts that it’s that it’s working well enough to recompile an entire game without a whole lot of hand holding.
I’m not watching a 20 minute YouTube video. But I did a quick search, and I’m guessing it’s about Box64, which does static recompilation. I’m still going to say that it’s not going to be perfect or even good enough in many cases (and their website indicates as much). You can’t always directly translate what happens on one CPU to another. Neon/SSE for example. You can do some translation, but some things will need emulating in software, and that’s going to be slow. Even memory access is different. I’m sure any programmer who’s tried writing a lockless queue is going to know that what works on x86 probably doesn’t work on ARM without a lot of futzing with memory barriers and atomic flags. It’s hard. And it’s hard because in order to be fast, it has to be the right code for the job. If you just slap a memory barrier after every instruction, it’ll run correctly, but too slow to matter.
This is why emulators exist, and continue to exist.
There is open source software to translate x86 to ARM, check this video out: https://www.youtube.com/watch?v=aP0yUqcyY18
The same thing can be done for RISC-V. Also there is not a way to translate xbox360 games and n64 games into C++ and then compile them for PC so they run natively. So the binary compatability thing isn’t an issue.
I personally have been daily driving a fully free and open source set of software on all my machines for years now, and I only really have issues with video drivers, and only then because I don’t want to switch to Wayland from X11. If RISC-V takes off and is viable as a desktop I will be able to run my exact same setup on it, the same way my raspberry pi can do anything my pc can. This is one of the perks of using open source, among many more. It’s a much better experience knowing that you and the community can solve any problem with a little bit of elbow grease, rather than being trapped by proprietary code with no way out. It literally feels freeing, I can’t really explain it.
I’m a bit out of the loop in the emulation scene. But the last time I was really involved, dynarec proved trickier than expected. I have my doubts that it’s that it’s working well enough to recompile an entire game without a whole lot of hand holding.
I mean in the youtube video I linked, she’s getting ~80fps in the original (non remastered) Crysis on an ARM device.
I’m not watching a 20 minute YouTube video. But I did a quick search, and I’m guessing it’s about Box64, which does static recompilation. I’m still going to say that it’s not going to be perfect or even good enough in many cases (and their website indicates as much). You can’t always directly translate what happens on one CPU to another. Neon/SSE for example. You can do some translation, but some things will need emulating in software, and that’s going to be slow. Even memory access is different. I’m sure any programmer who’s tried writing a lockless queue is going to know that what works on x86 probably doesn’t work on ARM without a lot of futzing with memory barriers and atomic flags. It’s hard. And it’s hard because in order to be fast, it has to be the right code for the job. If you just slap a memory barrier after every instruction, it’ll run correctly, but too slow to matter.
This is why emulators exist, and continue to exist.
I found a YouTube link in your comment. Here are links to the same video on alternative frontends that protect your privacy: