Category: RetroArch

We have started spotting a recurring trend of bad faith actors (it’s often times the same handful of people, with their own disingenuous reasons for pushing this meme) continuing to make bad-faith arguments that Libretro cores lag behind ‘upstream’ (whatever they think this means, often times they’re not even sure themselves or get it wrong) and that they’re out of date. In the past we’ve simply brushed it off as FUD (Fear, Uncertainty, Doubt) that attempts to muddy the waters, and therefore let it go unaddressed, hoping our users can separate fact from fiction by themselves. Unfortunately it’s the Internet and the more times you repeat a lie, over time people start parroting it.

So let’s set the record straight:

• We take great care in making sure Libretro cores work as best as possible. Despite similar bad faith actors making strenuous arguments that we provide no additional added value to cores, it takes a lot of hard work and effort to make sure that programs (whether they be emulators/games, or whatnot) are properly integrated into the Libretro app lifecycle so that they run flawlessly within a Libretro frontend, such as RetroArch. There is no simple ‘port and compile’ button that one clicks when making a Libretro core. When making a Libretro core, you dig deep into the internals of a program, you figure out how the runloop works, and you reimplement it. Sometimes a program makes that easy to do because its own internal runloop is already setup well for this, other times it requires a lot more effort. To make a long story short, all this takes hard work and effort, and we try to do it on a consistent basis in a way that provides additional added value to the user. Whether one core might not fit that description does not invalidate the vast majority of cores where this is the rule, and not the exception.
• We have spotted a recurring trend where endusers tend to overestimate the importance of random commits made to ‘downstream’ projects. While we try to work with devs when the opportunity arises, there are instances where we need to have a shallow fork of a project and judiciously do backports when such a mutually beneficial arrangement doesn’t work out. In this case, it has to be said that not every single commit that ever gets pushed to a repository is of importance, or even important to a libretro port to begin with. For instance, an update to some GUI framework is often times completely unimportant to the Libretro core.
• We work hard on a per-daily basis to keep cores updated as much as possible. Updates go instantly live on a daily basis through RetroArch’s builtin ‘Core Installer/Updater’ service. You literally can’t have it more fresh off the press. We think that repeated claims and heckling over random cores being ‘not up to date’ is putting an unfair and exhausting strain on us where we are pressured into continuing to walk on some hamster treadmill so that an enduser can finally get a ‘rebased’ core with some inconsequential commit that has no bearing at all on the Libretro core. We simply aren’t going to fall into that deathtrap.
• We update projects as much as possible and we try to make sure in the process that they continue to run well. Keeping a core updated is one thing, but you also want to ensure that it continues working on the platforms we care for, that the performance is maintained, etc. We go above and beyond the call of duty to pay attention to these things. We feel it is unfair that all this hard work and labor goes unnoticed and instead people engage in unfair levels of navel gazing over random commits that they themselves have no idea what added value they add to the core, whether it’s even baked in for the Libretro core, etc.

To dispel another set of rumors, no, Dolphin has not been ‘outdated’ now for months, Citra is getting a rebase soon, PPSSPP has not been ‘outdated’ for months. We are working hard on our new infrastructure at the moment where these cores can get rolled out. If they are not on our old buildbot right now, chalk it up to still having to recover from a rather nasty server hack that left us incapacitated at least for half a month or more, and we are still not completely done with the current server migration. We are completely confident that our project will be running better than ever before Christmas hits and that our new Libretro infrastructure will allow us to get things done much faster and much more efficiently than before.

Please note, it’s fine to point out when certain updates can benefit a Libretro core, certainly there can always be outliers and there can always be cores that could do with some improvements. But above being demanding, what matters even more is just contributing the necessary changes. While we are very grateful for the contributors we have, they already put in a lot of work as is in their own spare time. This kind of constant pressure to ‘update 24/7 around the clock for every nonconsequential commit I see happening on a repo’ is a problem. We do not want our pool of contributors to be overburdened or stressed out with these requests especially when the users in question cannot even tell us to what extent these contributions matter. We ask people that they leave it up to us to determine in these cases the pace at which we update repos, what changes are immediately merged in, what comes later, etc. It’s simply tiring and exhausting to continue seeing these talking points being pushed in an effort to discourage people from using RetroArch when we know ourselves just how much work, effort and time we put into all this to provide our users with the best possible experience they can get. Often times we even add features that are not even in upstream, or entire renderers are being written from scratch to provide a superior experience.

In short, there are some cores that are completely upstream, with commits fresh from upstream, without us even being involved. There are other cores where we do maintenance of the Libretro core ourselves because we deem it is the best option there. We’d like to ask the users that are insistent on these day-0 updates to please have some faith that the creators of Libretro/RetroArch in this case are perfectly capable of determining what is best for the user and to let us work at our own indiscretion. Every single update being pushed to a repo cannot just be mindlessly pushed, there has to be a filter and a process to ensure that for instance a platform we support continues working, that performance is not adversely affected, etc. We run a holistic framework here and we try to establish a truly crossplatform game console platform here that goes beyond the scope of nearly any project out there. The net we have to cast in terms of things to care about and what factors to take into consideration simply is much larger than is the case with most projects.

So, in summary:
* No, cores are NOT outdated. We have over 150+ cores and we simply DO NOT have time to tell you about every single change or update we push to our repos. It would be an inhuman amount of work for a team of our size, and any time spent writing patch notes would be time being taken away from working on our project and maintaining the stuff. Often times we push updates like over 3 or 4 times a day for various cores. We simply cannot give you status updates for all of this beyond just a ‘cores have been updated, click this button so you can immediately update them’. So people have to take their poison there. We are not Microsoft here with tenthousand workers working around the clock.
* And in the event a core *might* not be completely ‘up-to-date’ compared to some random ‘downstream’ (in the case where this is important and relevant), not only does the core still work fine and perform well (seriously, sometimes you don’t have to update exactly this very minute, sometimes things are just fine in a stable form), but we are usually quick to respond, and one or two exceptions to the rule does not give anyone the right to overexaggerate and make bad-faith arguments that they are ‘all outdated’. Also, these issues could be alleviated even quicker if we had more contributors that would join us in taking care of some of the workload. As it is, a lot falls into our lap and we are happy to accomodate, but that also means we work at our own pace and we determine what is important, and we are completely within our right to prioritize this according to our timetable.
* Furthermore, we often add features that are not even in any standalone version. Not to mention making completely new things like ParaLLEl RDP/RSP. It’s simply not true that you are ever going to get a ‘worse’ experience with RetroArch, quite the opposite. We feel these are simply bad faith arguments being made in a flimsy attempt to discourage people from trying out RetroArch. We put great love and care into our project to make it the best it could be, and it is rather upsetting to keep seeing these same talking points being trotted out by the same people, so we felt that since ignoring the nonsense doesn’t make it end, it’s time to address it.

We thank you for your understanding and we hope that we have managed to set the record straight on some of these things. Rest assured, we want to provide you at all times with the best possible experience when it comes to gaming. We completely believe in RetroArch becoming the ultimate be-all end-all crossplatform gaming console, and our passion for this is boundless. We will see it through to its conclusion no matter if not everybody shares our vision. Thanks for your time in reading this and we hope to provide some real quality new content for you soon!

P.S. RetroArch works Day One on Xbox Series S/X! All you need is a Dev Kit mode activation and you’re ready to go.