lr-scummvm: request for comments and testing

BuZz

@hhromic can leave it as O3. O2 is just our defaults

hhromic

@BuZz great, I will test more with the default O3 from the core. In general the scriptmodule seems to be evolving good and getting good reception and ideas, should be ready to submit soon :)

marus

@hhromic I tried to follow your instruction about repatching script but something is gone wrong, now i have to reinstall lr-scumm. Maybe you should write step by step how to uninstall and patch the script, at least for no experts 😉
No more time for testing these days, Once reinstalled i’ll give you some feedback, thanks again for your work!

hhromic

@marus oh, sorry to hear. Anyway is not such bad news as I now am no longer forcing O2 optimisation for the binary building, but the default O3 from upstream. This should create, in some cases, a better optimised/faster binary.

To uninstall, update the patch, and restart from a clean state (rebuild the binary), execute the following commands step-by-step:

cd $HOME/RetroPie-Setup  # go to the RetroPie Setup directory
sudo ./retropie_packages.sh lr-scummvm remove  # remove lr-scummvm core
rm -rf scriptmodules/libretrocores/{lr-scummvm.sh,lr-scummvm}  # remove scriptmodule and old scriptmodule data
patch -p1 < <(wget https://github.com/hhromic/RetroPie-Setup/compare/master...add-lr-scummvm.diff -qO-)  # re-patch with new version of the script
sudo ./retropie_packages.sh lr-scummvm clean  # clean any old build directory
sudo ./retropie_packages.sh lr-scummvm  # re-build lr-scummvm, configure and re-install

Then make sure your games are in the new format: .svm at the end of each folder name and a unique .svm file with the corresponding gameid inside each game folder.

Finally, restart EmulationStation and you should see your games under the scummvm system as single entries and not folders. If you click on any, it should immediately launch the game. You can also scrape the system too to get art and metadata for the games.

Take your time to test and let me know of your feedback when you can :), much appreciated!

BiZzAr721

Great work @hhromic . I want to share with you some information you may find useful.

During the evolution of OpenBOR on Retropie (now compiled from latest source, fully functional) with great efforts by @cyperghost, @darknior and @zanac, who has been paramount, & made us aware of GL4ES, which is a wrapper to provide OpenGL 2.x functionalty.

@zanac has compiled and shared his gl4es lr-scummvm binary, as well as recommendations for compiling with GL4ES, which retroarch can use natively!

https://retropie.org.uk/forum/topic/13784/openbor-finally-working-fine-on-retropie-with-es/299?page=15
(you can find the link to his lr-ScummVm core in post #307)

hhromic

@BiZzAr721 thanks for the support and for the information you shared.

I checked the post you referenced however I got a bit confused. The scriptmodule I'm proposing is pulling lr-scummvm from the official libretro repository here: https://github.com/libretro/scummvm. If I understood the post correctly, @zanac already mentioned that same repository for his build, so i guess his contributions are already there upstream? In that case his contributions to the core are already being pulled and used in this scriptmodule :)

Just to clarify, I'm not trying to port/adapt ScummVM to libretro on my own, but I am creating a retropie scriptmodule for building, configuring and installing the official upstream libretro core mentioned above to be as out-of-the-box experience as possible.

hhromic

Update
Good news about the annoying Random-Freeze-on-Quit bug of the core! I dedicated some time to try to debug the problem and I think I found a solution. At least for me, lr-scummvm is not crashing anymore when quiting games using the HOTKEY+START combo :)

I already updated the scriptmodule now to add a patch with the fix, I would really appreciate if testers can check if the freezing is gone when quiting directly from RetroArch (e.g. using the exit combo) instead of the ScummVM internal menu.
If the patch is confirmed to be a suitable solution, I will send the patch upstream and hopefully can be merged (this means for example Android builds would also be fixed cc @EctoOne ).

@marus , I hope you have the time to test the fix and report back on your side.

Edit don't forget to uninstall and re-install the scriptmodule (see OP instructions) to make sure you get the patch and the new scriptmodule.
Edit2 I tested with all my current games (see OP) and they all seem to be quiting now fine with the fix :)

hhromic

@BuZz , I would like some advice from you to improve user experience :)

I've been studying on supporting launching scummvm games directly from the game folder in EmulationStation (single operation) instead of having to enter the folder and launch the svm file in there (two operations). Also, by having ES recognising the folder itself, it's easier to scrape the games too.

I managed to make this work by means of a hack in the emulator entry of the scriptmodule in this way:

local -r emulator_cmd=(
    "$emudir/retroarch/bin/retroarch" -L "$md_inst/scummvm_libretro.so"
    --config "$md_conf_root/scummvm/retroarch.cfg" %ROM%/*.svm
)
addEmulator 0 "$md_id" "scummvm" "${emulator_cmd[*]}"

The method is very simple as you can see. When the game folder has a known extension for EmulationStation (.svm for example) then at launch %ROM% will be the folder itself in runcommand. Therefore, by adding /*.svm, runcommand will build the final cmdline with any .svm FILE inside the rom "folder" to pass to RA.

This works fine as long as there is a single .svm file in the game folder. However I think this can be done more reliable and elegant in runcommand itself.

My proposal is then to make a convention and make runcommand detect if the passed %ROM% is a folder, then search if there is a single file with the same extension as the passed folder inside, and if so, use the folder + file found as the final rom in the cmdline. This change is trivial and should be non-intrusive.

The most important benefit is that this would not force users to rename their scummvm game folders (keeping the two-clicks to launch if they wish), and users that do so would get the "one-click launch" feature. Currently, the hack in the scriptmodule requires that the folders be renamed with the extension of scummvm to be used as roms by ES. I believe some users might not get this at first.

If you believe this is a worthy argument/use case, I can make the modifications to runcommand, test them and send a PR for you to review. Thanks!

EctoOne

@hhromic Would your folder hack work for other systems as well?
I was always a little bit disappointed that I wasn't able to use the same subfolder structure which Kodi has (all game/movie related files in its own folder). That would make rom/asset management so much easier.

pjft

@hhromic I believe Daphne uses folders as well, if I recall correctly, so it might be good for inspiration to see how it is set up? Maybe there's something you can adapt from it.

BuZz

@hhromic I've only just scanned over your msg. Please can you do a PR and we can discuss it there so I don't forget. Need to check some code in regards to your idea.

Btw sorry I never posted my module. I couldn't find it. It's in a backup for sure, but don't think it's much use now anyway. It's pretty basic.

BiZzAr721

@hhromic From my understanding, those are just optimizations made to the make file which was made using make -j 4, and could possibly be applied using a patch, still building from source. Script-Fu master, @cyperghost may be able to give further insight. Maybe there is a simple solution to get games to load using the same files/location as the stand alone ScummVM.

I looked into the GL4ES, and I think the libretro ScummVM is already using it, therefore can use some of the advantages of OpenGL 2 (Where-as the standalone ScummVM runs off SDL). I don't know if additional dependencies are required.

Great to hear you may have solved the Freeze-on-Quit bug! I thought I finally had everything all set up just right, but now I'll have to give lr-scummVM a try!
Thank you.

hhromic

@EctoOne said in lr-scummvm: request for comments and testing:

@hhromic Would your folder hack work for other systems as well?
I was always a little bit disappointed that I wasn't able to use the same subfolder structure which Kodi has (all game/movie related files in its own folder). That would make rom/asset management so much easier.

What I'm proposing is not strictly tied to lr-scummvm, yes. However I'm not sure what you meant. To clarify, I'm proposing for runcommand to be able to do the following:

If the passed rom is a folder and the name has an extension, then search inside the passed folder for a single file with the same extension. If found, then use the combination of "passed folder/found file" as the rom to launch.
Otherwise, just behave like it is doing currently and do not transform the rom passed.

This would allow everything to work as it is doing currently, but in addition will allow for lr-scummvm games to be launched directly with one click from ES if the user suffixes the game folder names with the ".svm" extension. If not, then it will still work but the user will need to enter the folder first.
If other emulators support running roms in folders in this same way, then it should work too.

@pjft said in lr-scummvm: request for comments and testing:

@hhromic I believe Daphne uses folders as well, if I recall correctly, so it might be good for inspiration to see how it is set up? Maybe there's something you can adapt from it.

I will take a look, thanks for the pointer!

hhromic

@BiZzAr721 using make -j 4 is not a binary optimisation, just a build optimisation to compile faster. Currently, lr-scummvm compiles in less than an hour, so I just use the defaults from retropie. I don't know if GL4ES is used upstream in lr-scummvm but so far it is running very efficiently on my stock RPI 3B+, and others seem to be having good results too.

I'm already proposing an enhancement for runcommand to be able to launch games directly from folders, that should be robust, extensible and harmless enough to be integrated in RP.

I hope you can test the Freeze-on-Quit fix, I'm looking very forward to confirm it works to submit upstream :) Thanks!

hhromic

@BuZz said in lr-scummvm: request for comments and testing:

@hhromic I've only just scanned over your msg. Please can you do a PR and we can discuss it there so I don't forget. Need to check some code in regards to your idea.

Will do.

Btw sorry I never posted my module. I couldn't find it. It's in a backup for sure, but don't think it's much use now anyway. It's pretty basic.

No worries, the scriptmodule seems working fine so far :) Hope to send it soon to RP.

cyperghost

@hhromic @BiZzAr721 My knowledge about bash scripting is little. I'm stuck in building GLES out from the scriptmodule ;) Maybe I can use your script and rebuild it to this one openbor-6xxx

BiZzAr721

@hhromic Well, good news is I haven't had any freezing when exiting using HOTKEY + START! Navigating using joypad worked great, but my mouse would not work. (neither Trackpad incorporated in logitech KB, or corded USB mouse) Is there an option to allow joypad and KB & Mouse simultaneously? That's how the regular ScummVM core works. Mostly I will use the KB & Mouse combo, but I use joypad as well when I do not want to bother getting the keyboard.
Also, Speed Hack was disabled by default.

hhromic

@BiZzAr721 thanks for testing! I'm happy the freeze bug seems to be gone for you too.
Regarding using a real mouse/keyboard to play in ScummVM, I haven't tested that myself yet but will do to see how it works. Because RetroArch is focused on gamepad gaming, I suspect mouse/keyboard are mapped as gamepads by default. Will take a look and report back.

Regarding the speed hack disabled by default, as suggested by the official documentation of the core, it is only enabled automatically if you are installing on an ARM device. What platform are you using?

BiZzAr721

I am using raspberry pi 3b, running RetroPie 4.4 (Stretch)

hhromic

@BiZzAr721 for RPIs the speed hack should be automatically enabled. I tested on my RPI3 and RPI2 with stock RetroPie installed and in both it is enabled just fine.

By design of RetroPie, the speed hack core option will not be set if you already had it configured to any value, for example "disabled". This is to not overwrite any previous custom-configuration. I suspect that is what happening for you.

You can verify this by removing the core option scummvm_speed_hack in /opt/retropie/configs/all/retroarch-core-options.cfg and re-configuring lr-scummvm using sudo ./retropie_packages.sh lr-scummvm configure. You will then see that the speed hack is now enabled automatically.