Best way to list cores by system?

RetroArch General
#1

EDIT

The tip I got here panned out. I found some useful info that got me started on my project.

Feel free to add more thoughts, or move on knowing the world is a friendly place.

Thanks guys.

[HR][/HR]

Disclaimer: Rather new to retroarch, please bear with me if I’ve missed something obvious. If so, perhaps we can make it more visible / intuitive.

[HR][/HR] ::Key Goal::

I want to get a list of cores available for each system programatically, i.e. without going through the retroarch graphical client and with a preference for shell scripting.

I’m wondering what options there are for this, already available or to prepare myself.

[HR][/HR]

::Initial Research::

As far as I can tell, this is not currently an scripting or programmatic option already available.

[ul] [li] retroarch --help doesn’t seem to have any options for this. [/li][li]Cores are named after the emulator project and do not include a system name, so I can’t simply scan the filenames in the libretro directory. [/li][li]I have not been able to locate API documentation that would indicate how to do this outside of the command line. [/li][/ul]

Is there a tool already out there? Or do I need to create my own by resource explicitly?

In terms of preparing such a resource, I’m also short on resources which list the available cores by system.

This is what I’ve found.

[ul] [li]The retroarch application does this, but it’s not a copy / paste friendly situation. [/li][li]I looked in the libretro repositories, but couldn’t find my way to the information that populates the core downloader. Anybody know where this is? It might be ideal. [/li][li]The retroarch wiki lists cores in the format core -> platform. Same problem as using the file system (some emulators have non-obvious names or support multiple platforms). The compatibility list is a start, but doesn’t cover the full list of systems, so it would involve cross-referencing (ugh). [/li][li]The retropie wiki does this, but it also includes non-libretro sources. I would like to stick to libretro for now, and would prefer my resources did, too. [/li][/ul]

[HR][/HR] ::Background::

<snark>Since every technical forum post in the history of forums is inevitably followed by the we can’t help you if we don’t know why guy, followed by the don’t be greedy just do x guy: </snark>

For a hobby / learning project, I am developing simple tools to streamline installation, configuration, and integration emulationstation / retroarch on Ubuntu derivative systems. My primary use case is Linux Mint.

I realize that retropie is available for this, but I’ve found the project sources / structure to be nigh undecipherable, and this is much about me learning / doing and how that relates to other projects and goals.

Since I found my way to retroarch from emulation station, one of my first goals is to abstract away the need to identify core locations explicitly in the es_systems.cfg.

Instead of:

 <command>retroarch -L /path/to/nescore-libretro.so %ROM%</command>

I want to look like:

 <command>nes %ROM%</command>

Perhaps even, ideally, create an enhancement where the default is:

 <command>%PLATFORM% %ROM%</command>

Then, to switch the default core, or even another emulator, bash can be used, i.e.:

nes --set-core=quicknes

etc.

This way, I can provide sensible defaults, provide a platform independent configuration file, and combat the plague of tutorials that teach you how to do all of the configuration yourself, by providing a tool that actually does it.

From there I can extend it to support other emulators / options / command line formats.

[HR][/HR] Thanks for putting your eyes on this.

#2

Before any other advice, have you checked out Lakka? Maybe it is a suitable Linux-based RetroArch environment for your experiments.

#3

The core info files have the information you want. They’re located in the libretro-super repo.

#4

I have noticed Lakka, and I’m a pi owner. This is definitely something I’m excited about and pursuing separately.

As a focus for my hobbies and development, however, it has a couple of key flaws for my tastes.

  1. It’s reliant on the retroarch gui, which I don’t like. I actually strongly prefer the unthemed version to the PS crossbar style interface, and emulationstation is closer to my ideal case, something along the lines of wii-flow, which is the best front-end in my personal history of hackery game stuff. (ZSNES had a pretty sick vibe too, albeit not suited for a 10-foot situation).

  2. It’s divorced from the ppa / apt ecosystem, as far as I can tell. I’m trying to focus my personal projects in a way that gives me more exposure to debian publishing system and git -> linux build lifecycle.

  3. It’s a distro, not an application (at least as far as I can tell). I’m more interested in adding value to desktops (new & refurbs), rather than creating dedicated boxes.

  4. Following on that, as a lifelong emulator user, I was super excited to discover how retroarch had brought all sorts of elements together, only to get frustrated with the compilcation of getting it to interop with my controllers and another piece of software I got started. Plenty of people more enthusiastic about the pis are going to contribute in the Lakka / all-in-one department, and I feel like my interests and skills align on the more underserved command line interoperability side of the issue.

#5

Dead ringer on the info for sure. I’m glad I asked. libretro-super/dist/info is probably the last place I’d have ever looked.

I remember know seeing these files when searching for retroarch.cfg

So I can scan retroarch.cfg for libretro_info_path and that directory will tell me which cores are installed in libretro_directory.

Awesome.

<tangent> I will add it’s a little unfortunate that only long descriptions are included. A scheme of canonical shortcodes, (ala es_system.cfg <platform> codes; link) would simplify interoperability with other applications and packaging systems. There’s a lot of redundant info in these files that could be normalized, using a simple code.

I wonder? What other projects have adopted standards for this kind of thing. </tangent>

#6

The info files are a bit of a hodgepodge of whatever information RetroArch needs bridge the cores with the frontend. More fields could always be added. However, RetroArch doesn’t have any concept of ‘systems’, just cores, and it treats all cores similarly/equally, whether it’s an emulator or a game engine or a video player or whatever.

If there’s something you’d like to see added, you can come to #retroarch on Freenode IRC or open an issue at the libretro-super github repo.