Why I more or less don't like LibRetro/RetroArch

RetroArch General
#1

I am sorry to have such a first post, but I am honestly writing this so that one day I find my issues with the project resolved and embrace it.

One thing I love about it first of all. The portability it allows.

Now… My main issue with the project is that it looks like it wants to “take over” instead of “cooperate” and just step up to make existing projects better. What I mean: Someone makes a MAME core. NOT mame dev team, “someone” (maybe libretro team themselves I dunno). It is perfectly ok for open source code. I am not talking license-wise or anything like that.

I would expect that someone would approach mame team (or ANY other team, for example VICE or Toni of WinUAE or I don’t know) and present why libretro is a good thing and try to make the “core” build, one of the official builds. Has anybody attempted this ever?

I mean if I would see on mamedev.org (since I used it as an example):

mame0187b_32bit.exe
mame0187b_64bit.exe
mame0187b_libretro_32bit.zip
mame0187b_libretro_64bit.zip

…it would be fantastic and I would definitely try this more.

Now, my main issue (let’s call it #1) leads to other gripes I have with libretro and the main retroarch implementation…

  1. Why there is no option for updater to download ALL (per section eg. cores AND fully all)? Actually it should also be able to be scheduled (weekly or whatever) and filtered (only update existing). It is PAINFUL to manually click all the entries interested (esp. for some that want to research all) one by one. Even a multi-select would be better than the current thing. In some older version (haven’t verified if it still has this issue) if you clicked to download the next or the next and the one after it, the system got confused and STOPPED downloading (or extracting) the previous (asynchronous operation where are you?)… Hope this is fixed.

  2. Versioning of cores and even metadata (like thumbnails). I am not sure if there is INTERNAL versioning, but there is nothing to show the user! You have for example “VICE” core, but you don’t know (easily) if it is the latest and actually even updater itself doesn’t help… you can click to download “VICE” 10 times in a row. There is no mechanism to tell you “well you already have it and is latest, so don’t push me!”… Especially for MAME the classification (by some important to mame development, years) is almost funny. Why not use the actual MAME versions to name the cores?

(2+3 bonus) Actually there is nothing in updater to tell you that you have something already downloaded (a change of label color for example)…

  1. There is no indication on WHO makes a core. Except dev (or team) names, I would expect something like “Official” (implying involvement of original to the specific emulator devs), or “LibRetro made” (by LibRetro team themselves, which is the next best to official) or “LibRetro verified” (by 3rd party but abiding to some rules and having checked) or “Unofficial” (for the rest).

…so… For something that was created to IMPROVE existing emulation projects (and more), you definitely have a long way to go even for basic things.

I have faith that these will eventually be rectified, but also I am afraid (as with any open source project) that if any of these don’t trigger any dev to actually make them (or the one who asks for those can’t code himself), they may never come.

Again sorry for the “attitude” of this first post, but if I didn’t have any faith in the project, I wouldn’t bother posting.

#2

1.) yeah, that’s how we do it all the time, actually, and we have a number of cores that are either officially upstreamed or created with upstream involvement. However, upstream is sometimes hostile, and in that case, we take the initiative and provide the cores we want to provide, as long as the license permits. Some members of the MAME team have been quite hostile while others have been more friendly/receptive; however, we’ve largely buried the hatchet with them as a group and hope to have a more positive relationship with them in the future.

It’s important to recognize that for most devs/teams, someone showing up and saying “hey, do a bunch of work to integrate some interface/codebase you know nothing about because it’s good for our users/project/ecosystem” is not an attractive prospect. Unfortunately, even when we do the work and offer it up on a silver platter, many projects’ response is “no thanks,” so we keep it going ourselves.

Other than that, it seems most of your issues stem from how our online updater works. If you don’t like that, don’t use it. Download the cores once at release time (or compile yourself from git if you want to know all the nitty-gritty details) and then just keep using them. As for organization, if you don’t like how our project is run, fork it and start your own. Don’t come here and say “hey, do a bunch of work so all your shit works how I think it should.”

We never said we’re trying to “improve emulation.” We’re making an interface to play games the way we want to do it (at great personal expense in both time and money) and giving it away for free for anyone to enjoy. If it doesn’t work like you want it to, either get coding or don’t use it.

3 Likes
#3

You reply started nicely (thank you for your reply to #1) but then you went on to the old popular “fix it yourself or get off our back” (which is another way to say “if you don’t dev, you are a clueless nobody that doesn’t deserve an opinion that we consider at all”).

(which is funny because I did start as a dev my 30+ years involvement with computers - more than half professionally - but my career has moved far from coding, so I cannot make anything much more complicated than “hello, world” in -quite a few- languages inc. assembly code for 3 once popular CPU platforms)

Anyway, I hope my post gets a second look, because really asking for something like retroarch to allow multi select downloads or some kind of versioning implemented (and displayed), is not subjectively “how I personally think it should work” really.

Keep up the good work.

#4

What sort of response were you expecting, honestly?

As you pointed out, it’s your first post here and it has an accusatory/dismissive tone. That’s not going to make you any friends anywhere, but especially not at a free, hobbyist open-source project.

I have nothing against non-devs. I started out as one (we all do, of course, but even specifically talking about RA/libretro) and still only do light dev work. However, when people say things like “fix it yourself or get off our back,” it’s because someone has to do the work, and if you’re not volunteering to do it, that means you think I should.

Ok, now we’re getting somewhere. Is this really the meat of what you wanted to find out? Multi-select/download queue is surprisingly difficult to do in our case. You might find it easier to go to buildbot.libretro.com and download cores via your web browser and then place them into your cores directory manually. You can also see the date for when that core was last published/updated in that same web interface.

#5

Start reading the Issue trackers for the key libretro repos on github: Retroarch, Lakka-LibreElec, libretro-super, libretro-database, libretro-thumbnails, libretro-assets, probably a few others.

Keeping up with all of the discussion and the PRs for the main repos takes only about 15-20 minutes a day. I do it most days when I’m in my tinkering mood. That is where all discussion hits reality. You will learn the answers for all your questions and more.

If you do that for about two weeks, I believe you will start to find opportunities to make a difference directly on at least one or two things you care about. That’s all it will take, consider it :wink:

3 Likes
#6

nulusios maybe give it another try later or see it growing over a while. in some case (f.e. Mame Cores, CD-based Systems) it isn’t really userfriendly but allmost usabel at least. But thing getting better and better :slight_smile: and YOU can help with reporting issues or finding workarounds to change things for a ultimate retro-gaming solution.

Have you ever tried Lakka (all in a box system) instead of Retroarch ? http://www.lakka.tv/

1 Like
#7

If updating the cores is really the only thing you don’t like about retroarch, you could easily cook up a script to automatically download the selected cores you want from the buildbot. You can set the script to run periodically, or use it for launching retroarch

In linux 64bits it would be as simple as a few wget lines with the different urls you want, with the “-N” flag to ensure you don’t redownload files you already have if there was no update (and “-ou” when unzipping to overwrite only if new):

wget -N https://buildbot.libretro.com/nightly/linux/x86_64/latest/gambatte_libretro.so.zip
wget -N https://buildbot.libretro.com/nightly/linux/x86_64/latest/dolphin_libretro.so.zip
wget -N https://buildbot.libretro.com/nightly/linux/x86_64/latest/mgba_libretro.so.zip
unzip -ou "*_libretro.so.zip" -d  YOUR_LIBRETRO_CORE_DIRECTORY_HERE

I don’t know about Windows, but you could do something similar with powershell or just use msys, cygwin or similar.

Btw, it’s too bad there isn’t a “latest” directory for “stable” in the buildbot. It seems you can only have a static url to update the nightlies, not from the stable ones.

1 Like
#9

That’s actually not what he said though, he explained a little how they do things and gave you several options to what you are doing. Your complaints really are based on your subjective views on how libretro and the cores should be managed which honestly is like you going into NASA and trying to tell them how they should build rockets.

I’m sure they are all for humble critique but your post just comes off as negative, which you seem to understand yourself as you are apologizing for the attitude of your first post. I could tell just from the subject that this was going to be bad. Maybe a “my personal experiences with libretro/retroarch and what i wish was different” subject would be more well receieved? If you want to contribute, try to ask and learn why things are the way they are instead of assuming that the devs haven’t given any thought at all to these things?

As someonelse mentioned, get on github and take a close look at what’s going on with the different cores. Look at what kind of changes are being done to them, how many committers. Look at the Lakka build scripts, find out how it all ties together. Are you sure mass updating the cores from a nightly build run is a good idea to begin with?

Things can always be better, but what they have already achieved is nothing short of amazing. Libretro have completely revolutionized the emulator scene already and we are getting it all for free.

7 Likes
#10

Just a quick note the mass download of cores has been brought up many times and I believe the most common answer is that it would produce to much bandwidth load on the community funded servers

1 Like
#11

Multi-select/download queue is surprisingly difficult to do in our case.

According to https://github.com/libretro/libretro-super/issues/339 a user offered to implement it himself almost a year ago, for the build process (actually, the build process has the reverse issue: someone wants to not have to download all the cores at once and retroarch doesn’t support that).

#12

The issue OP had was with RetroArch’s built-in core updater. That link is for the libretro-super build scripts. Not really related. I’m hizzlekizzle in that thread, btw.