i30817
commented
6 years ago I'm closing this because i've been thinking about it and libretro doesn't have to reinvent the wheel. If the upstream fs-uae-launcher can be made to work on the cmd line, offline (after a download step ofc), without QT etc dependencies and with a mode to extract the game into a 'dh0' form it could be use by the fs-uae core to create the 'dh0' and the libretro-database could use it to collect all the settings it needs to autoconf (given the games again, which is not hard).
upstream fs-uae has a way to boot WHDLoad games directly into the game, which turns the Amiga emulator pretty much into a 'console' emulator because the whdload archives are read only and they have a autoconfig database.
This database would be useful not only for whdloads but the floppies (that also don't change crc on well behaved games).
This is the issue open on libretro-fsuae and my comment of this there : https://github.com/libretro/libretro-fsuae/issues/13#issuecomment-387002925
I feel this is a 'chicken and egg' thing. Collecting the database and configurations doesn't sound like a difficult problem¹ (it's on openretro and it has a api sufficient enough for fs-uae-launcher to get configs, but not sure if they download it all at once (ideal) or search for the game (annoying but scrapping url python does well). Getting updated games is not a big problem either because the 'most updated' (whdload) collection is small (4gb). ADFs crcs can probably be lifted from TOSEC or no-intro, whatever project collects them, but i'm not sure it's easy to match to a database name (may be though).
After matching the (filename and crc) to the x_name, you have the rest of the game configuration necessary and can massage that into a clrmamepro entry to create a autoconf database for the fs-uae core.
After that it's their problem (and it's a problem for whdload at least, since unzipping lha and making it work on native filesystems is kind of hard, not to mention the caching behavior). I think the games (WDHLoad at least) will get dumped into /saves/fs-uae if this ever happens.
Basically, I'm asking for a collaboration between libretro-database maintainers and the libretro-fsuae maintainers to circumvent this 'chicken and egg' problem. Even if the autoconf doesn't happen now having the database ready with the information (even if it doesn't end in users downloads yet) would future proof it too.
¹ You can't just 'use' the database itself without slowing down the scanner immensely because the way that works in fs-uae-launcher is by name ( i believe). If there is a file checksum verification it's likely only the file_list field of the database. The main 'lha' file is not stable for various reasons (timestamps, etc)... unless we canonize one of them, which is what this issue is proposing. Similarly, even the uuid or dh0_sha1 is suspect, because although the uuid used by fs-uae-launcher as a name/id of the fabricated 'directory' hardrive, it's only after all the files are scanned and as for the dh0_sha1, it's actually different from the lha sha1. Not sure if it's possible to create the hard_drive before scanning considering that the 'hardrives' fs-uae-launcher creates are actually native directories (maybe they get seen like a hardrive by the emulated amiga and it's possible to create that sha1 from inside the emulator).
The answers to the above indeterminate questions are on the fs-uae-launcher code.
Another (maybe better) idea is to take advantage of fs-uae-launcher and ask for a
cmd linemode from upstream, where you pass a game and get a configuration out and even a extracted lha to the directory you choose.