Lakka 3.3 has just been released! To learn more, check out this article on our sister site Lakka.tv here.
This version is based on the latest RetroArch version, 1.9.7.
RetroArch 1.9.7 has just been released.
Grab it here.
If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.7 version) is scheduled to be released a week from today.
Remember that this project exists for the benefit of our users, and that we wouldn’t keep doing this were it not for spreading the love with our users. This project exists because of your support and belief in us to keep going doing great things. If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!
NOTE: We will update this notice as soon as we have uploaded the 1.9.7 version for UWP/Xbox as well to our server. For now, these still point to the previous version (1.9.6). We thank you for your understanding.
A brand new platform port has been added for RetroMini RS-90 (and similar devices). These are low-powered mass-produced MIPS handheld devices that are sold for very cheap. To us, it is yet another opportunity to optimize our cores for low-end devices.
PlayStation2 users are in for a treat. gpSP (Game Boy Advance emulator core) has been optimized and tuned for PS2 to the point where it should run most games at fullspeed. RetroArch should also have a bitmap font driver implemented now instead of relying on gsKit like before.
WiiU users benefit from many improvements to file I/O optimizations (faster loading/startup times), network speed, and menu/font rendering.
Switch users should benefit from the 7zip compatibility added to this release.
Many improvements to the CRT SwitchRes feature have been made. For more details, see ‘Changelog’ below.
Following on from the success of our OpenDingux port for JZ4770-based handhelds, we are pleased to announce official support for RetroMini RS-90 devices running OpenDingux Beta. This tiny console has one of the weakest CPUs we have ever targeted; it has just 32 MB of RAM, an ultra-low resolution 240×160 display and is available for as little as $20 – but still it provides an enjoyable RetroArch experience.
Given the limited specifications of the hardware, a modest section of cores are available. The following generally run at full speed:
…while these offer varying degrees of playable content with frameskipping enabled via core options:
For the best results, we recommend applying a per-application CPU overclock for the RetroArch application: highlight RetroArch on the device’s home screen, press the select button > Edit RetroArch, and set Clock Frequency to 420 MHz (depending on the chip, a lower value may be required, or even higher may work correctly).
Yeah! It’s real and it is coming! GameBoy Advance running perfectly in #PS2 😮😮 . It never worked like that 🙌🏾 #RetroArch and #GPSP core using #dynarec made the magic. Thanks of @davidgfnet for his huge collaboration.#GBA #Castlevania @libretro @TuberViejuner 👾 pic.twitter.com/ErdSoY3oAo
— Francisco J. Trujillo (@fjtrujy) July 10, 2021
It is really beautiful to see this marvelous intro running in the #PS2 totally smooth. #RetroArch with gpsp core. We never saw something like this before, thanks @davidgfnet @libretro
Please enjoy it! 😍😍😍#GameBoyAdvance #Retro #PS2Dev pic.twitter.com/ACNDh1q97D
— Francisco J. Trujillo (@fjtrujy) July 21, 2021
gpSP should now be available for RetroArch PS2 starting as of version 1.9.7. This is a Game Boy Advance emulator core. Davidgf has been working hard on this core for the past few months and the results speak for themselves – this should be the first time that a PlayStation2 is able to run Game Boy Advance games at fullspeed.
In addition to the improvements listed for WiiU previously, there’s also the following to mention:
Fix inputs breaking when connecting/disconnecting remotes
When a KPAD controller (Wiimote, Pro Controller, etc.) gets disconnected or has its accessory changed, the Wii U’s API gives nonsensical results for a little while, even while claiming these results have no errors whatsoever. This was wreaking havoc in the input system and ended up leaving the controllers useless.
1.9.7 attempts to work around the console’s API by filtering out some of the unknown results.
Download progress indicator fixed for large transfers
An important bug was fixed that was causing issues while downloading the Assets from within the program. When downloading a large file on a 32-bit platform, the progress indicator will get pinned to 100% after downloading roughly 40MiB. This causes a lot of stress for assets.zip, where the 40MiB mark is about halfway. This bug has been fixed. Note that this improvement is not only beneficial for WiiU but should benefit other 32-bit platforms in general.
1.9.7 provides a workaround for the long-standing issue of “protocol error” messages being written to stderr whenever the “Suspend Screensaver” option is enabled and the X11 context driver is used. These messages don’t actually come from RetroArch – they’re xdg-screensaver’s, which is a script for cross-DE screensaver suspending that RetroArch calls to do its job.
It turns out, the script has a problem with title-less windows. See the related bsnes issue for analysis – kudos to Screwtapello for figuring this out. The proposed solution is to check if there’s already a title, and if there isn’t, to set it to a single “space” character, which is surprisingly enough for xdg-screensaver to work. The space character is picked so that there’s no visible difference between the bogus title and no title at all. The alternative is to make sure that RA’s window has a title at all times – too much of a hassle for something this trivial.
1.9.7
RetroArch 1.9.6 has just been released.
Grab it here.
If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.6 version) is scheduled to be released a week from today.
Remember that this project exists for the benefit of our users, and that we wouldn’t keep doing this were it not for spreading the love with our users. This project exists because of your support and belief in us to keep going doing great things. If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!
Be sure to also read our Libretro Cores Progress Report (a link will appear here later).
Windows users (with XAudio2 audio driver): RetroArch would previously hang/lock up if you happened to disconnect your current audio device. For instance, this could happen if you were playing with headphones on and you decided to suddenly disconnect your headphones. This has now been fixed. Instead of it locking up the program, instead the sound is just lost instead.
Security concerns over the AI Service on Windows have been addressed.
Improvements to the Windows installer have been made. This should hopefully prevent potentially disasterous situations from happening again. This could happen for instance when the user pointed the installer to install to a directory he should not be pointing to (like C:\Program Files for instance or the desktop), and did not heed the warning.
Linux users should hopefully no longer experience crashes when toggling between normal and threaded video mode with OpenGL thanks to a patch by grant2258.
The Direct3D 11 driver has been improved for Windows users thanks to Stenzek (DuckStation author). Several fixes: tear control support is queried. If not supported, flip mode presentation will not be used and Direct3D will resort back to the legacy blit model instead (less optimal and worse windowed mode). DXGI Alt+Enter handling has been disabled since it would conflict with RetroArch’s fullscreen mode switch. Non-vsynced output without the flip model should also be properly fixed now, when tear support is enabled and flip model is used, it should be possible to fastforward.
When scanning content, the amount of time required to push each new entry to the resultant playlist increases exponentially with playlist size. For small romsets this is typically unnoticeable, but when dealing with very large data sets (e.g. arcade romsets) scanning quickly becomes impractical. A full arcade romset can take several hours to scan – or days on Linux (where certain file operations that are a NOOP on Windows, etc. are very slow).
This happens because the ‘push entry to playlist’ routine is highly inefficient. It has to check whether the entry being added already exists in the playlist, which requires a content path comparison – which in turn involves several expensive operations to resolve ‘real’ file paths and deal with any inconsistencies in archive path notation. The problem is that these expensive operations happen every time: push an entry to the playlist, and it will process and compare every existing content path until it finds (or does not find) a match; push another entry and it will process every path again. Once a playlist hits a couple of thousand entries, this constant reprocessing grinds the scanning process to an effective halt.
1.9.6 solves the issue by caching all parameters derived from content paths on first use, so when pushing multiple entries to playlists the expensive path operations are only carried out once per existing entry. In addition, hash keys are used to minimise lengthy string comparisons. This greatly improves the efficiency of content scanning – and also of playlist management features (since these require nested playlist searches, which now also use the cached content path values/hashes).
For example, before with 1.9.5 and earlier, it was effectively impossible to scan 100k files. Now with 1.9.6, on a low spec development machine running Linux:
* A manual scan of 100k files takes 20 minutes
* Performing a Clean Playlist operation on the resultant playlist takes 5 minutes
1.9.6 adds support for the remapping of individual controllers to arbitrary core input devices. This allows multiple controllers to be assigned to one input. To configure this, a new Mapped Port option has been added to the Quick Menu > Controls > Port N Controls menu:
Here, the Port 2 Controls refers to the physical controller; Mapped Port refers to the core port that will receive input from this controller.
For example, to map physical controllers 1 and 2 to the player 1 input of a core, set the following:
* Port 1 Controls > Mapped Port > 1
* Port 2 Controls > Mapped Port > 1
There are various use cases for this remapping:
* It allows multiple controllers to be used when playing hotseat multiplayer games that normally support only a single controller
* It allows hybrid-type controllers (e.g. two joysticks mounted in a cabinet) to be used as a single device
* It allows easy swapping of player 1/player 2 (etc.) inputs – for example, when the PSX version of Metal Gear Solid asks the player to plug their controller into port 2
Note that these configuration settings are independent from the main RetroArch config file. To make any changes persistent, a Core, Content Directory or Game remap file must be saved.
1.9.6 also cleans up a long standing issue when configuring remaps: before, changes to Device Type and Analog to Digital Type via the Quick Menu while a core is running will ‘bleed through’ to the main config file. This is harmful and unintuitive behaviour. With 1.9.6, the global settings for these values are cached when initialising a core, and restored when the core is unloaded. (This essentially became a necessity for using the port remapping functionality, since it is rather easy to create complex configs that should in no way touch the main config file…)
RetroArch is able to map the left or right analog stick of a gamepad to D-Pad input via the per-port Analog to Digital Type menu setting. Unfortunately, this is a ‘trap’ for new users: mapping a stick in this fashion disables its analog input, which creates confusion when using cores that have native analog support. Many users enable Analog to Digital Type by default, then complain on reddit/discord that analog controls do not work for PSX/N64/etc. games.
1.9.6 modifies the Analog to Digital Type functionality such that it can be disabled automatically for cores that have native analog support. The setting now has the following values:
* None: No mapping
* Left Analog: Map left stick to D-Pad, but disable mapping if core attempts to read analog input
* Right Analog: Map right stick to D-Pad, but disable mapping if core attempts to read analog input
* Left Analog (Forced): Always map left stick to D-Pad, disabling left stick analog input
* Right Analog (Forced): Always map right stick to D-Pad, disabling right stick analog input
In addition, a sublabel has been added to the Analog to Digital Type menu entries, which should help to explain what they actually do.
Finally, this PR required some modification of input overlay-related code, during which the following bugs were fixed:
* There is no longer contention between analog stick inputs when an input overlay and physical controller are attached to the same port
* Input overlays no longer generate analog stick input in addition to D-Pad input when Analog to Digital Type is set to the left or right stick
Several security-related improvements have been made to the AI Service functionality for Windows in an attempt to address concerns that this could be abused. Speech input is no longer sent as a commandline argument to PowerShell, and both the language and speed parameters are properly sanitized and only allow for a few hardcoded safe values to be passed now. This should mitigate most of the attacks that could be thought of with regards to injection.
Several safeguards have been put in place to prevent people from making a severe mistake during the installation process on Windows. With the installer program, it is no longer possible to install RetroArch to a directory that has existing files or subdirectories. Instead, it has to be written in a new directory. We have to insist on this because the uninstallation process involves wiping RetroArch’s entire directory and everything in it. In the past, people could have made the mistake of pointing it to “C:\Program Files” without putting it in a separate subdir, with disastrous results on deinstallation. While the installer program did warn about this and asked you with a dialog prompt if you were sure, nevertheless we cannot take this risk to begin with. This has been resolved by simply deallowing this to happen by forcing you to install RetroArch to a new empty dir.
1.9.6
Hi there community,
last Sunday a tragedy befell the emulation community, when Near tragically took their own life. While we feel Near needs no introduction, we feel it is only right to let people know of the extent to which Near’s work laid the foundational framework of Libretro/RetroArch, and what other great projects they worked on, including of course bsnes (which needs no introduction at this point).
Among Near’s other great accomplishments: libsnes (which later turned into our fork, libretro), libco (a cooperative multi-threading library), Higan (a multi-system emulator), Ares, and various other auxiliary projects.
Out of respect for Near’s untimely passing, we have delayed the release of the next RetroArch by a full week. You won’t be seeing us doing any promotional material or coverage for it until then, and who knows, we might even skip going into it at all. We feel this right now is more important and should get front and center coverage.
We asked three people familiar with Near to provide their own eulogy. Recognize that we speak from the heart and that our purpose in doing this is to pay proper respect and tribute to a great programmer in the emulation scene, the likes of whom we might never get again.
About 15 years ago, I was just getting into open-source software and the Super Nintendo was always my favorite console, so I was excited to find a relatively new open-source emulator that ran even the weird, unpopular games. The author of the emu had a forum where they posted their releases and all the cool stuff they were working on, and that forum was home to a tight community of other smart, creative folks.
That forum was the old bboard, and that emu author was, of course, Near. As we all know, Near was extremely prolific, driven in their pursuit of perfection, and generous enough to share their many accomplishments with the world at large. In addition to their work on bsnes, Near also documented their relentless reverse engineering escapades on the bboard, along with their efforts to understand the entirety of as many facets of software development as they could, top to bottom. The bboard was home to some pretty epic (in the classical sense) threads in which Near would dive head-first into topics–like the fundamentals of signal resampling–that most of us outside of graduate-level computer engineering programs consider black magic.
It is no exaggeration when I say: without Near and the community they cultivated on the bboard, there would be no libretro and no RetroArch.
Libsnes (which would serve as the basis for libretro) was Near’s design to decouple their backend code from the endless frustrations of frontend coding. The bboard is where Themaister first developed and released SSNES, which would become RetroArch. They met Twinaphex while attempting to port bsnes to the PS3 via libsnes+SSNES on Near’s behalf. To this day, many of our cores depend on Near’s libco cooperative threading library. I could go on.
With that said, we did not always agree or even get along. Near’s perfectionism frequently put them at loggerheads with individuals who felt some thing or other was already “good enough” (that is basically the tl;dr of how libsnes became libretro), and, on a personal level, I do not presume Near considered me a “friend” (or even thought of me much at all, for better or for worse). Like most of the people reading this, I suspect Near had a much larger effect on my life than I had on theirs.
Nevertheless, I hope Near understood the immense positive effect they had on my life and the lives of countless other individuals, not just through their numerous accomplishments but also as a compassionate and insightful human being. The world is a less-interesting place now, without Near.
We were never the closest friends; I was around for a while, but I was always more interested in bsnes than you, Near.
I now realize I was wrong. Too many open source maintainers are valued only for their contributions and otherwise taken for granted, leading to tragedies like this.
May you finally have the peace you were denied in life.
I have been a bsnes fan since the very beginning when it was first announced. I remember running Mega Man X2 on an Pentium 4 PC at the time in 2005 with a premature version of bsnes and feeling that finally there was an emulator that could get the sound exactly right, and it played exactly right. Those are memories and experiences that I will always cherish.
I was not even really involved in programming until around half a decade later. I had a chance meeting with Themaister around 2010 when Near was trying to see if bsnes could run acceptably well on a PlayStation3. This was my first introduction to Near back then as a non-user and to me this meant a lot. We pretty much got stuck at the 50fps mark, but what that chance occurrence did show me was the massive potential of libsnes as an emulation abstraction layer and how easily software could be ported across platforms so effortlessly without having to maintain multiple copies of a codebase per platform. I was sold there and then on the entire potential of libsnes and SSNES. And one thing lead to another.
Fast-forward to 2021 and it’s been well over a decade since the project started and I’ve been running it now for all this time. You now know of libsnes as libretro and SSNES as RetroArch but the core concept has remained fundamentally the same, right down to the same API. Where there was in 2010 only one emulator implemented as a core (bsnes), now there is nearly 200 implementations, and not all of them even emulators. The only credit I can take in this is that I have put an inhuman amount of time in building the road so that people will come with daily maintenance and coordinating of projects so that everything works well within Libretro/RetroArch as an ecosystem. But Near absolutely deserves the credit for coming up with the foundational pillar on which this all stands.
For what it’s worth, I regret that for a long time, we did not see eye to eye, and at one point there was a fair bit of animosity between us. Thankfully in 2017 we were able to shake hands and leave the past for what it was. There were hurt feelings, disgruntlement and disillusion on both sides about the emulation scene, the way it was becoming more commercialized and co-opted by commercial interests [from private correspondences I can confirm this bothered Near deeply too], the sides people took in that while it was happening, and people getting in the middle trying to amplify those grievances and wounds. I apologized then, but I will also apologize in the present for how things went before.
Like indicated earlier, I was a fan of Near’s work before I got involved myself in the scene, and going into this had nothing but the highest admiration and apprecation for Near’s work. Ultimately the last thing I wanted was for there to have been a falling out. I tried reaching out many times before trying to squash this situation since ultimately I regretted that it had come to this and felt it should not be like this. Ultimately without a mediator I was getting nowhere with this.
In 2017, thankfully all of this we were able to put aside forever thanks to the help of a mediator, and both sides assumed good faith from that point forward. I was hugely relieved by this and took this very seriously on my side. I was committed from this point on to show that not only was there always appreciation and respect, but even more importantly, I wanted to show this not in words, but by action. Since then, I worked together with Near on many occasions. This includes involving them in a Eurogamer article about emulation licensing and helping them with license abuses from third parties. Various email correspondences centered around emulation and the libretro project have been exchanged and we had been active supporters of Near’s Patreon. Additionally contributors upstreamed libretro support into bsnes in 2018 sparking various collaborations and friendly terms. Another example is the libretro-backed Parallel RDP project where we encouraged themaister to help integrate it into the N64 emulation in ares for accurate graphics emulation. I am grateful and thankful we were able to do all these things together. To date, my biggest regret is that we had that unfortunate initial falling out in late 2010. But, I am grateful to Near that there was the willingness to leave the past behind in 2017 and start over again. Ultimately, it could have all been so easily avoided and the things that divided us were ultimately so minuscule as to not even matter.
While I won’t profess to be a brilliant coder myself, I do recognize brilliance and potential where I see it. And projects like hiro, libco, and libsnes definitely show that raw genius that was in Near. Hiro for instance was a crossplatform GUI wrapper that would wrap complicated OS-dependent windowing APIs around one common abstract interface. There exist other examples like this but it was well designed and versatile, and used to full effect in Higan/bsnes. I would be remiss not to point out another great invention, libco. It’s a cooperative threading library, very small in size, that allows one to jump from one place to the next without resorting to actual real ‘threading’. Libco’s legacy (and thereby Near’s legacy) lives on in many libretro cores today. And libsnes needs no introduction, it morphed into libretro and has largely stayed fundamentally the same.
Near’s last few projects were equally as important. Ares was a multi-system emulator that covered all sorts of classic game computer and handheld computers from the ’80s to the early ’00s. One contribution that came from us was the aforementioned Parallel RDP Vulkan-powered plugin which would allow fullspeed accurate video emulation of the N64, as well as Parallel RSP. But Near also had spent nearly a decade or more on a translation of the videogame Bahamut Lagoon, which they considered their magnum opus. This was a painstaking work of passion with the kind of attention to detail few other localizations can boast. Near actually started this translation before even creating bsnes itself, as the Bahamut Lagoon translation was the catalyst for bsnes to emerge as a project. Current SNES emulators at the time had a lot of issues that were difficult to work around, with Near preferring a more clean approach without resorting to all the hacks.
I’m afraid it will be highly unlikely we will ever see a programmer as gifted involved in open-source emulation again, certainly not one with as much commitment and passion. Everyone with an appreciation for the Super Nintendo (yes, even Nintendo themselves) owes a huge amount of debt to Near for doing the near impossible in documenting and preserving this system and its back catalogue for all of posterity. It is very rare that you see someone with such selfless commitment dedicating themselves towards fully preserving a system.
Near was a very kind and sweet person, who cared for others. They were very talented and was amazing at what they did. I hope that they have found peace.