The Libretro blog covers RetroArch and the libretro emulation API, including new emulator cores and the project's open hardware work.
HN commenters link it as the home of RetroArch, a multi-platform emulator, and defend the site as ad-free and Mac-supported through MoltenVK.
Fully solved how? It's in a great state.
Angrylion brought a new paradigm to n64 emulation, which is "fuck it, Low Level Emulation is fully doable now", and then that incredibly successful work was ported to run as a GPU shader, where it works a million times better! Now even medium powered devices, like the Steam Deck, can run low level emulation of n64 games at upscaled resolution and never run into graphics bugs, have fewer other bugs, have great performance, etc.
Classic bugs like the perfect dark remote camera that always had trouble on High Level Emulator plugins are just gone, no tweaks required. Games that wrote their own microcode run with no trouble. The crazy shit Rare and Factor 5 did at the end of the console's lifecycle just works in emulators.
https://www.libretro.com/index.php/category/parallel-n64/
Notably, Modern Vintage Gamer released a video titled "Why is Nintendo 64 emulation still a broken mess in 2025" and to make that video he had to contrive dumb scenarios: Running n64 emulation on the Playstation Vita and a Raspberry Pi.
Efficient and accurate high level emulation of the n64 is just not possible. You can't properly emulate the complex interactions going on in the n64 without huge amounts of overhead, it's too interconnected. Angrylion and Parallel-n64 proved, with that amount of overhead, you might as well do pixel accurate low level emulation and just eliminate an entire class of emulation bugs. When angrylion came out, around 2017, even a…
What would be interesting is if there were a language-agnostic library that handles the annoying and complicated game engine things like optimizing the list of OpenGL draw calls or pooling audio resources, which would take forever to buggily reimplement - then have people write bindings to it in whatever arbitrary language they want.
For example there is a version of the LOVE game engine that targets ChaiScript instead of Lua[1].
What I really want is a version of LOVE that targets a lightweight LISP like Janet.
(I know, fennel exists. But imagine having a battle-tested game engine like LOVE in any LISP at all.)
And yeah, I'm implying LOVE should be that library. They have pretty much everything you'd ever need for a gamejam. I'll never touch GL.h again.
As for what the author of DOME says on exposing fewer abstractions than LOVE, I found I didn't have to muck around with low-level details like window resolution that much. LOVE provides the functions wrapping all that and preventing undefined behavior while benefiting ergonomics. The process of resizing the window which took far longer than it should have for me to get right in C++ is handled by a single call to love.window.setMode - and it handles hidpi and fullscreen and stencil buffers and MSAA and a bunch of other things[2]. Imagine implementing all that yourself, supposing that yes, you really do need that stencil buffer in the future. The work has been done already.
Where LOVE's very large standard library…
http://rss.slashdot.org/Slashdot/slashdot
https://www.raspberrypi.org/feed/
https://www.aclu.org/taxonomy/channel-term/1/feed http://gpuopen.com/feed/ http://feeds.feedburner.com/armdevices?format=xml
http://mobilesemi.blogspot.com/feeds/posts/default
http://feeds.feedburner.com/cnx-software/blog?format=xml
http://boingboing.net/feed
http://atomicsupermen.wordpress.com/feed/
http://feeds.feedburner.com/Gizchinacom?format=xml
http://semiaccurate.com/feed/
http://anandtech.com/rss/
http://www.fudzilla.com/?format=feed
http://semiengineering.com/feed/
http://www.fark.com/fark.rss
http://feeds.reuters.com/reuters/oddlyEnoughNews?format=xml
http://www.clickhole.com/feeds/rss
http://www.reddit.com/r/nottheonion/.rss
http://www.phdcomics.com/gradfeed.php
http://www.smbc-comics.com/rss.php
https://xkcd.com/rss.xml
http://media.nxp.com/corporate.rss?c=254228&Rule=Cat=news~subcat=ALL
http://blog.nxp.com/feed
http://www.engadget.com/rss.xml
http://feeds.feedburner.com/IeeeSpectrumFullText
http://static.fsf.org/fsforg/rss/news.xml
https://stallman.org/rss/rss.xml
http://freegamer.blogspot.com/feeds/posts/default
http://www.phoronix.com/phoronix-rss.php
http://feedity.com/futuretimeline-net/VVFXVFdV.rss
http://www.vivantecorp.com/index.php/en/media-article/news.feed?type=rss
https://9to5google.com/feed
http://www.xda-developers.com/feed/
http://www.androidauthority.com/feed
http://www.androidpolice.com/feed
https://news.ycombinator.com/rss…
RetroArch and Vulkan based projects in general are supported on Macs, since RetroArch has integrated MoltenVK.
For this particular project, it's up in the air whether it actually works. Parallel RDP is not a "standard Vulkan game", and if I understand correctly behaves more like a compute shader program written in Vulkan. As a result, it requires the presence of certain more niche Vulkan extensions. MoltenVK by its nature is not as "feature rich" a Vulkan driver as bare metal Vulkan drivers are, so it might be missing extensions required for Parallel to work. In Parallel RDP's first iteration, it required a Vulkan extension that allows GPUs to use system memory, which was only present in certain Windows/Linux GPU drivers but not in MoltenVK. There's already a workaround for this with a minor performance impact.
Parallel RDP now seems to work on a few mobile GPU Vulkan implementations [1], which would be encouraging for MoltenVK as those drivers tend to be lower quality and have less coverage also. Maybe Parallel RDP already works on MoltenVK in fact, and just requires some testing [2].
[1]: https://www.libretro.com/index.php/parallel-n64-rdp-android-support-and-intel-igpu-improvements-what-you-should-know-and-what-to-expect/
[2]: Worth noting it has only been released for Windows and Linux so this would require some building yourself: https://www.libretro.com/index.php/parallel-rdp-rewritten-from-scratch-available-in-parallel-n64-right-now-for-retroarch/
Nothing you said has any grounding in reality.
https://libretro.com is ad-free
No hardware I tested has any problems with any emulator and most emulators still run better than the main port.
If you were referring to another retroarch site you went to the wrong site which could explain your problems, but please open a bug report if you really have such a bad experience with retroarch and maybe try another libretro frontend.
Sadly I consider your comment as FUD since I can't collaborate/verify any of your problems on any hardware... I'm sorry. If you really downloaded retroarch from a non official source, please check your PC for malware.
Edit just to clarify I'm not associated with retroarch even though I provided code a few times in the past. I'm still using it from time to time, but I hadn't had contact to anyone from this project for years. I'm just an independent dev who hates FUD...
Use Lakka, not RetroPie. Use a PS3 controller—360 would work, but its dpad is terrible, and both work with no extra effort. PS3 even works over bluetooth with little to no fiddling. Only trick is you have to find the "right" roms (those blessed by various projects that record hashes of accurate rom dumps) or Lakka/Retroarch's auto-rom-scanning won't work, though you can still select roms manually. Small price to pay for the level of "just works" that Lakka provides.
[EDIT] links:
http://www.lakka.tv
Which romsets to use for various systems:
http://libretro.com/forums/showthread.php?t=6661