VFS support

[garbear]

Feature description

I'm bringing up this issue because there's a feature I've started working on. It'll require rcheevos patches, and I'm wondering if it would be acceptable for merge.

The problem to solve is that fopen() is called in this library, but often times a frontend will be loading a game from a SAMBA share or from within a zip file.

The solution follows the path of RetroArch, which added a VFS API so that cores can access games on a VFS (first proposed by me in 2016).

Requirements and drawbacks

The downside of a VFS API is that they seem to be proliferating. RetroArch has an extensive one with 19 functions. Kodi has the equivalent, and I've started exposing kodi's vfs to libretro cores (kodi-game/game.libretro#58). It'll add a lot of code.

However, I think we only need a subset of a full VFS API, which would be these seven functions:

• get_path()
• open()
• close()
• size()
• tell()
• seek()
• read()

Motivation

The motivation comes from my GSoC student, who finished his project early and went on to add a unique feature: machine captioning of savestates (garbear/xbmc#120).

He even kept going and managed to connect live presence to discord (garbear/xbmc#123).

Being able to caption savestates of games on SAMBA and within zips would be cool.

Thoughts?

[Jamiras]

Open, close, tell, seek and read are already abstracted through https://github.com/RetroAchievements/rcheevos/wiki/rc_hash_init_custom_filereader for most of the uses. When needed, size is calculated using seek to end and tell.

[garbear]

I didn't see those. That makes my life easier :) I'll open PRs if I need to patch anything.

[garbear]

We've added VFS support to kodi-game/game.libretro#67. @NikosSiak verified it worked. Thanks for pointing me in the right direction.

Before closing this issue, I noticed some UB (undefined behavior). This occurs if the client passes NULL to rc_hash_init_custom_filereader() here.

Kodi also has a problem, in that the custom filereader is a binary add-on API to Kodi, and binary add-ons can be loaded and unloaded. Therefore, the custom filereader can be invalidated.

To fix both problems, what if we have rc_hash_init_custom_filereader() unset the filereader if NULL is passed? This is sensible and desired behavior, because then we offer a "deinit" function for filereaders to safely unregister themselves.

[Hedda]

@garbear is #98 a solution for your issue?

[garbear]

Looks like that solves my problem. Thanks, issue closed!