Command line arguments

[heuripedes]

The current libretro API does not support a way to expose command line arguments to the core. This is something desirable in "standalone" cores (RA - HAVE_MENU + statically linked libretro) like media players.

One possible implementation of this is exposing core options in the frontend's --help so that the user could set options only for that session. The advantage of doing it this way is that it doesn't require changes to the libretro API, the issues are:

1. Needlessly long command line switches, e.g. --3dengine-location-camera-control-enable=disable
2. Shorter (unprefixed) command switches may clash with the frontend's own command line options, e.g. a *-record option would make the frontend expose --record which is interpreted by the frontend.
3. No support for arbitrary values like file names (this is a limitation of the core option API).

Another implementation is exposing a preprocessed (without frontend arguments) argv to the core via an environment call or a modified retro_init. This requires changes in the API and core-side interpretation of the arguments but allows arbitrary arguments/options.

Examples

frontend player_libretro.so song.mp3 --convert-to=wav --output=song.wav
mupen64plus "Wipeout 64 (USA).zip" --gfxplugin=rice
cowadoody map.zip --cheats
cadapp --enable-threads

[Alcaro]

Interesting idea, but I'd rather fix the core option issues instead of creating some kind of almost-core-options.

For #1(): Why not tell RetroArch to track core options separately for each core, so we can get rid of those random prefixes entirely? I don't like them either. For #2: Let's prefix with --core- in case of conflicts. Or maybe always prefix with --core-, so options won't randomly change meaning after an updated RetroArch adds a new one. We'll risk collisions no matter whether we put these extra flags in core options or elsewhere, anyways. For #3: Partially fixed by 68222af2. Not sure if we need arbitrary strings, but it will be easy to add if needed. () Shut up GitHub, that's not an issue. Didn't you learn anything from this?

(Edit: Shut up GitHub, (*) means footnote, not italics.)

[heuripedes]

Some uses for arbitrary strings:

1. URLs
2. User profiles
3. Nicknames
4. Hostnames
5. Paths relative to the loaded content
6. Content-specific information like entity IDs

[Alcaro]

Paths relative to the loaded content are filenames. User profiles sound rather similar to filenames too, but are probably directories instead.

I don't see why the core should care about URLs; there's no way to handle that without platform-specific code, and cores shouldn't contain that. URLs can be argued to be some weird form of filenames, too; minir on Linux is happy to load the ROM 'http://example.com/snes/smw.sfc', but I think I'm the only one.

I'm not sure why the core would want hostnames, either; that sounds like something only netplay should be concerned with, and netplay belongs in the front.

Nicknames and entity IDs make sense, though (nicknames are part of netplay, but the core may want to render them above the players' heads, and the front doesn't know where that is). I never said I don't want arbitrary strings, just that I didn't add them yet. (I think we need a way for the front to tell which kinds of variables it can process. At this pace, we'll have ten kinds before libretro v2 is even released.)

Either way, this issue is about whether the extended core options can be used to represent command line arguments. Assuming arbitrary strings as core option values are allowed (they'll probably be soon enough, anyways), are there any other reasons why core options would not be the best way to do this?

[heuripedes]

User profiles sound rather similar to filenames too, but are probably directories instead.

These could also be identifiers to stuff inside the SRAM.

I don't see why the core should care about URLs; there's no way to handle that without platform-specific code, and cores shouldn't contain that. URLs can be argued to be some weird form of filenames, too

A media player core would care about URLs like "mms://foo.com/" to stream video/audio and a multiplayer FPS would be interested in "mumble://myserver:8888" or "teamspeak://bar.com:9999" for team chat. The frontend shouldn't be bothered about these.

I'm not sure why the core would want hostnames, either; that sounds like something only netplay should be concerned with, and netplay belongs in the front.

How'd netplay work in the case of a FPS with a dedicated server like openarena?

(I think we need a way for the front to tell which kinds of variables it can process. At this pace, we'll have ten kinds before libretro v2 is even released.)

Arbitrary strings should cover all cases IMO, even the weirdest ones.

are there any other reasons why core options would not be the best way to do this?

Nope.

[Alcaro]

These could also be identifiers to stuff inside the SRAM.

Good point. The front shouldn't care what's inside the SRAM, it's all a binary blob.

How'd netplay work in the case of a FPS with a dedicated server like openarena?

My ideal solution would be that the core tells the front to create a socket; the frontend does that and passes the packets on. If the front knows it's talking to another RetroArch (detected using some unspecified magic method), it's allowed to encapsulate the packets to add chatting and whatever else it can think of; if the front does not know that the other end can handle it, it disables the GGPO anti-lag rewind because netplay plus savestate equals boom if the other side doesn't know what a netplay is. It should be possible to use the same mechanism for URIs, too. We can add a "don't ask the user, connect to here instead" entry in the netplay env struct, then give the core the URI and let it parse it (possibly using some simple helpers in libretro-sdk). Either way, the exact details on how netplay should work is out of scope for this issue.

are there any other reasons why core options would not be the best way to do this?

Nope.

Then arbitrary strings in the core options (plus the other v2 core opt changes) is all that's needed to mark this one resolved. Added in 6400f5d.