Integrating lr-mess quasi-cores into RetroPie-Setup

theburgerking

Hey dev team, I have been contributing to @valerino's branch of RetroPie-Setup for a while now, primarily exploring and adding support for some of the many systems supported by the mess ecosystem.

I would like to start the process of getting his work reviewed and promoted so the world can much more easily emulate and enjoy those systems. He is bought in to this effort, I am here to help and facilitate.

Valerino's branch contains a number of areas of new work in addition to the lr-mess core expansion - hdmi/crt parallel simultaneous configs, fixes to various other emulators, and introduction of various other emulators. I am happy to help on all of them but I would like to start with the mess work.

The general idea in case you are not familiar is to build "quasi-cores" on top of lr-mess, which are code-less configs within the mess ecosystem. They capture the desired default bios, media, and other options at an emulated-system level as a core (vs at the lr-mess level, which would not make sense). To a user, they are independently installable, updatable, and removable.

Some questions:

If a core requires a helper script, where would that best be located? I would think that in general ~/RetroPie-Setup/scriptmodules/libretrocores/<corename> is a good place but in the case of lr-mess there is the issue that the helper script would need to come from the RetroPie-Setup repo and not the mess repo, so I am not sure how that would work. Right now the new helper script is in ~/RetroPie-Setup/scriptmodules, where it works well but is definitely mess-specific. Thoughts? I could echo out the file from the lr-mess.sh script to the desired directory if needed but that seems a little hacky.
What are people's thoughts in general about the quasi-core appoach in general? It is a minor paradigm shift from the standard, but because mess is a truly massive ecosystem of its own (1000+ systems emulated plus another 1000+ clones), I believe it is worth it to allow for special handling.
Because of the potential proliferation of lr-mess-<system>.sh scripts under the mess umbrella, it might be interesting to consider a new submenu within "Manage packages" for this work. On one hand that would make the work fairly isolated and insulated from other changes, on the other hand it would make it less discoverable to users.

There may be other questions as well but these should give me what I need to get things ready for review. Thanks.

zerojay

Personally, I really like the concept however I think that the sheer amount of scripts you're adding here is going to keep it from being added to RetroPie. That's adding a lot more possible work to be done in terms of maintaining the scripts if they are a part of RetroPie officially.

I think I currently have the largest repo of original scripts for RetroPie at the moment and I used to try pushing them into RetroPie-Setup, however I realized that I was going to be generating more and more work for jools and the team by doing so, so I decided to stop and just keep them in my RetroPie-Extra repo instead. I figured they are aware of the repo and if they wanted to bring something in, they know where to find me.

If you're looking to make them more visible and available to people than they are now, you can always send me a pull request on RetroPie-Extra and I'll gladly accept them. (I had been working on something similar a few years back but never got around to making it public and finishing it off.)

BuZz

If it's to be implemented in RetroPie-Setup - I am likely going to be fussy about the method used. My way of wanting to do things may not be the same as the current implementation.

I have thought before about giving lr-mess the ability to do more configuration, and envisaged an additional gui for that.

I've not had a chance to look at any recent code so I'll have a look. Maybe I can implement something you could then contribute to, but I can't promise anything.

If it's the code I saw before it just wasn't suitable for integration, but some of the other modules could have been but I think they were all submitted together? I may have my wires crossed or remember wrong.

Also bear in mind, that everything submitted needs to be maintained. There has a been a lot of stuff I've had to rework that has broken over time and the original contributor is long gone :-) We include a huge amount of packages. Not trying to be negative, but I'm often for an idea, but not necessarily how it's implemented.

theburgerking

Sounds totally reasonable. If we are talking about opening up a new subsection of functionality then it may very well make sense to put a sub-gui on it.

You remember correctly that Valerino's first pull request was all-inclusive, for both lr-mess and his other added features. This is one of the reasons I suggested just looking at the mess-derived feature set first.

I think I can potentially refactor things to use more of a generator pattern so that there is less boilerplate to maintain - right now the quasi-core scripts are probably 95% the same with the only differences being the accepted file types and the actual addEmulator line(s). I am up for doing that if it makes review and maintenance easier, but I am a little stuck on thoughts around the packaging of the run_mess.sh helper script, which is the one that assembles the temporary .cmd file used to actually bring up the lr-mess core with the right options. If we can get aligned on that point then I can work on things in the background while you do some thinking about whether/how you want to incorporate functionlity under the mess umbrella in general.

I am also ok to not pursue this if the consensus is that it is a non-starter, my only motivation is that getting involved in the mess stuff opened up a whole new world of systems to me - old game consoles, old computers, and a ton of standalone handheld games like Simon that I otherwise would not have had the chance to experience.

Thanks all.

mitu

Have you thought about using the mamepackage instead of lr-mess ? It might be easier to configure thanlr-mess.

theburgerking

Tell me more, I am not sure what the advantages and disadvantages would be.

The "difficulties" in using lr-mess for emulation of arcane systems (look at this monster list!) are mostly around getting the cmd file ready to run to disable softlists, since the lists for these ancient machines are much less useful, and figuring out which media options are available to be used for each of those machines. Those are really the only 2 things that happen in each of the sub-module scripts, and it does work well and predictably.

What are your thoughts on mame as an alternative? (I am still learning here so thank you for your patience with these questions.)

mitu

Some advantages I see when using mame directly

can start mame (mess) with the right system without relying on the folder (parent) name to detect the system/driver. Might be addressed in the run_mess script, but it would be easier to use addEmulator and set-up mame with the right parameters.
mame has a pretty extensive configuration hierarchy, which allows to create per-system .ini file where you can set ROM/BIOS locations. For instance, when loading the coco3 system, mame would look for mame.ini, computer.ini, coco3.ini, etc. You can set per-system configuration files - i.e. to to specify the ROM/BIOS locations - when configuring a specific system through an additional .ini.

mitu

Now, the disadvantages I see firsthand are

the lack of RetroArch's auto-configuration for gamepad/joysticks - you'd probably have to tune the configs for each system.
it's harder to configure shaders and MAME favors HLSL shaders (through the BGFX renderer), which are not going to work on a Pi. GLSL shaders are still available, but both options have to be set by editing configuration files, as opposed to RetroArch's UI for shader control.

theburgerking

That is extremely useful info. Now we have reached the point where I ask 2 truly noob questions.

Is there an lr-mame core? Could I build one? I have used lr-mess both prebuilt and built from source and I see from its build script that it just pulls from https://github.com/libretro/mame.git.

And second, it seems to me when I do a generic internet search for an old system, let's say the ACT Apricot for argument's sake ("mame apricot"), the results I get are all news of mame support for that system and links to bios downloads. Does this mean that mame itself is the part of the mame distribution that can run that system? I had thought I understood that it was the mess part of the distribution that would handle systems like that. I guess I can formulate the question better as "how can I tell what to run on mame and what to run on mess?"

Noob central here, thanks for indulging me.

mitu

@theburgerking said in Integrating lr-mess quasi-cores into RetroPie-Setup:

Is there an lr-mame core? Could I build one? I have used lr-mess both prebuilt and built from source and I see from its build script that it just pulls from https://github.com/libretro/mame.git.

Yes. Both lr-mess and lr-mame are built from the same codebase you mentioned (forked upstream MAME), but with different build options, which results in different supported systems (arcade vs. non-arcade).
I was referring to MAME (the upstream project), not the libretro cores.

Does this mean that mame itself is the part of the mame distribution that can run that system?

Upstream MAME distributes only 1 binary which supports all systems included - either arcade, computer, mechanical, etc. There's no separate MESS anymore and I think hasn't been for quite some time.