ScummVM and libretro ScummVM: One .svm-File to Rule Them Both

Lolonois

Using ScummVM and libretro ScummVM side by side and run games either in ScummVM or libretro ScummVM does still not fit well yet.

This is a brief followup to [1] and [2].

With a little structure in the filesystem scummvm and lr-scummvm could be used seamlessly alongside.

I have updated my branch with a proposed solution [3] to fit into the latest RetroPie-Setup.
If the Python part is too much, then at least the filestructure should be in a way that from a game launcher file *.svm the matching game folder can be identified. The identified game folder can then be provided to libretro ScummVM and the auto target is run in that game folder by the libretro implementation.

My approach followed in the branch is to have this folder structure:

RetroPie/roms/scummvm/
...
├── Touche - The Adventures of the Fifth Musketeer
├── Touche - The Adventures of the Fifth Musketeer.svm
...

and touche as game id in the *.svm file.

With this structure the game folder can be determined by the romdir-launcher.sh which is sufficient to run the autodetect from libretro for that game.

The python part is more ease-of-use and enabling config changes for games to be stored in each scummvm.ini file.

Can we craft a solution for this long standing issue?

[1]github.com/RetroPie/RetroPie-Setup/pull/3430
[2] https://retropie.org.uk/forum/topic/32058/scummvm-lr-scummvm-launcher-and-interoperability-improvements
[3] https://github.com/Gemba/RetroPie-Setup/blob/fb_scummvm_lrscummvm_scriptmodules/scriptmodules/, see libretrocores/lr-scummvm.sh, emulators/scummvm.sh and supplementary/scummvm/scummvm_helper.py

mitu

@Lolonois Thanks for putting this together, I'll take a (new) look at this over the week-end.

mitu

Hi, sorry for the late reply.

I agree with the changes needed to be implemented in order to accommodate the standalone/Libretro core launchers supporting a single .svm file - I think we already had this conversation.

I do however find the implementation could be simplified (leaving aside the python helper, which I haven't looked over since I see it as optional). Here are my notes:

once a svm file is found, scummvm should just be launching the game and no extra checks should be done (i.e. no --detection). If the folder path is not found (based on the .svm basename), just launch without it.
comparing the pre/post game lists - the comparison should be triggered only if the .ini files's timestamp is modified. Maybe sha256sum should be replaced with something simpler (md5sum would be enough, crc32 would be even easier - but it's not a native program).
.svm files should only be created after the launch is complete, not before.
don't do symlinks in the roms folders, it's not going to work on (Ex)Fat32 drivers when an external media is used. Just create the .scummvm file in the game's folder for the Libretro core and have it launch from there.

Lolonois

I have redone the +Start Scummvm.sh script [1], sharing it here for discussion. It still contains development output and verbose comments.

I am not done with the libretro part, just removed/rewritten a python-less version.

once a svm file is found, scummvm should just be launching the game

Which requires a matching [section] in the scummvm.ini to identify the game path. This requires currently (upstream main branch) to run Add Game in the UI. Which IMHO creates a clutter in the roms/scummvm folder and would the libretro implementation to consult the non-libretro scummvm.ini.

Maybe it is advisable to move a step back and align about what a user must/should/could and may not do when deploying ScummVM games?

Some options:
a) The user MUST run Add Game or Mass Add... for the games.
b) The user MAY NOT manually edit any generated .svm files
-or-
c) The user MAY edit new/exisiting .svm files and uses as content c1) the game id (as in the ScummVM compability matrix, example bladerunner) or c2) the target as provided by Add Game or --add (example: bladerunnner-final-win) or c3) the content of the .svm file is irrelevant, the filename represents the target (=expected [section] in scummvm.ini)
d) The user MAY create empty .svm files to force automatic --add on launch.
e) The user MAY edit the section names in the scummvm.ini, but SHOULD keep the corresponding .svm aligned and vice versa.

The upstream implementation uses a), c3) and e). But misses d) which will cause an error when a bladerunnner-final-win.svm file is found but has no peer section in the ini. It has no "error correction" for e).

Apart from the envisioned interoperability with the libretro counterpart the suggested change uses: a), c1), d), and e). It comes with the price of a larger launcher script but strives to keep the launch dependency faultless even if the user does accidentally something wrong.

comparing the pre/post game lists [...]

I am using diff now which is sufficient.

.svm files should only be created after the launch is complete, not before. [...]

Unless the user provided an empty .svm I stick to your suggestion.

don't do symlinks in the roms folders [...]

Will adress that in the libretro part.

So in short before proceeding: What is the decision on user responsibilities and script capabilities?

[1] https://github.com/Gemba/RetroPie-Setup/blob/fb_scummvm_scriptmods_simplified/scriptmodules/emulators/scummvm.sh