when need_fullpath is false, retro_game_info::path contains the content filename

[markwkidd]

Note: AFAIK there is no reason to suspect that this change would affect any existing core or frontend implementations, because retro_game_info::path is currently not guaranteed to have any particular contents when need_fullpath is false.

If accepted, this proposal would mean that moving forward frontends would set retro_game_info::path to the filename (aka basename) of the content being loaded.

My previous PR helped clarify the existing behavior of RetroArch with regards to the value of retro_game_info::path when need_fullpath == false. There is now consensus that this part of the documentation accurately describes the way RA works.

This PR is my attempt to express the proposal that is currently being discussed in the beetle-gba discussion where this all started: libretro/beetle-gba-libretro#33. I hope that it will be helpful.

[garbear]

Is the data guaranteed to come from a file? Kodi can play games from any source, including web streams or (in the future) from two files, a ROM and an .ips patch. What would the filename be in these cases?

[markwkidd]

That is a good question.

The use case for this string is to have a content-specific filename for the core to use when saving game data, etc.

Maybe rather than specifying that the path be the content filename when need_fullpath is false, the API should merely specify that path will be "a unique and valid string". Therefore the frontend might use the content basename as the path if the content is a file being loaded from disk, but use an IP address, etc if the content has a non-filesystem source.

[garbear]

I am against making string parsing a part of the API. Maybe the filename can be provided by the VFS API?

[markwkidd]

Can you explain what you mean by string parsing? I'm suggesting that it would be up to the frontend to put together the string as it does at present -- there need be no string handling in libretro.h or maybe I don't understand.

My amended suggestion was merely that the path string be unique and be valid to use a file. The frontend could determine whether to return the filename, some network address converted to a string, a string-formatted hash of the content, etc.

edit: The frontend could definitely pull a unique from the VFS API as far as I could see. My suggestion would be to make this specification as general so frontends can be flexible. As long as cores know they are going to get a unique string that can be used to identify the save files, etc. for the content cores should probably not be relying on that string being the name of a file, or a network address, or any other particular thing -- just that it's unique and can be used for save files.

[markwkidd]

Old news! Back in 2012 this was actually part of the libretro spec in 4.1.7: https://github.com/libretro/docs/blob/097fad73646edb6dba449d0a9af3b37eaad61c4e/archive/libretro.pdf

If need_fullpath is set to false, the frontend will load the ROM image into memory beforehand. In this mode, the path field is not guaranteed to be non-NULL. It should point to a valid path if the file was loaded from disk, however, it is possible that the file was loaded from stdin or similar, which has no well-defined path.

It helps explain why this is the behavior already seems to match this proposal. Somehow that sentence didn't make it into libretro.h at some point.

The trouble is -- what to do about the scenario where content is being loaded from sdtin or similar, which isn't reflected in my PR as currently written