lr-scummvm: request for comments and testing

mitu

@DarishZone What's the error ? Post the actual error and maybe we can find a solution.

DarishZone

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

@DarishZone What's the error ? Post the actual error and maybe we can find a solution.

I'm sorry but i don't have that, i'm pretty sure install, which is loong indeed, interrupt with some error on terminal then a message on Emulation Station, seems it not compile for some reason. I will eventually try again and takes some photos, thx!

zefolhadela

@Dipkid me too same network aswell and faild to install..

hhromic

Hi all! I've been traveling and didn't have time to catch-up the forum.
there were some recent commits to the lr-scummvm upstream that changed the Makefile, maybe it broke.
Yes, @DarishZone if you can post the error that would be very useful. Anyway I will also try to compile the core soon and see what is going on. Thanks for reporting!

jandalf81

I just tried installing lr_scummvm on a fresh install and was greeted with the following error:

Could not successfully build lr-scummvm - ScummVM port for libretro
(/home/pi/RetroPie-Setup/tmp/build/lr-scummvm/backends/platform/libretro/build/scummvm_libretro.so not found).

When scrolling a little bit up (I used SSH) I see

collect2: error: Id returned 1 exit status
Makefile:424: recipe for target 'scummvm_libretro.so' failed
make: *** [scummvm_libretro.so] Error 1

and a lot of undefined references above that. The error seems to happen quite at the end, the build process ran for 1h 15 before that...

mitu

@jandalf81 There should be a full log file of the installation under ~/RetroPie-Setup/logs - check the most recent one. It would be good if you'd get the file and upload it's contents to pastebin.com to take a look.

jandalf81

@mitu Yeah, sorry. I submitted that post too fast. I'm uploading to pastebin as I type this, will update with a link any minute now

EDIT:
The upload to pastebin failed (it's too large). The whole log (still in the gzipped archive) is here: https://www.dropbox.com/s/zrlw601gzuihsuf/rps_2019-01-11_194137.log.gz?dl=0

hhromic

@jandalf81 thanks for the log. Indeed the recent commits broke the build for RPI at the final linking stage, hence why it takes a while to compile but fails at the very end. By the looks it seems it needs some flags adjustment in the Makefile.

Unfortunately I won't have time today to fix it, but if you are comfortable using the console, what you can do in the meantime is to force compilation to the last working commit.

With an editor, e.g. nano, open the file $HOME/RetroPie-Setup/scriptmodules/libretrocores/lr-scummvm.sh.

The first function in the file is sources_lr-scummvm(), in there find the line:

gitPullOrClone "$md_build" https://github.com/libretro/scummvm.git

and replace it with this:

gitPullOrClone "$md_build" https://github.com/libretro/scummvm.git master 20d71cd7189ae7fdd453a3041f3103bffabea13e

Afterwards save the changes, exit the editor and try to install again.

When I figure out what is going on will update. Thanks!

DarishZone

Will test that fix in the meanwhile! Thanks

hhromic

@DarishZone thanks! let me know if it worked for you. As soon as I have some time I will take a look to fix the issue properly

DarishZone

@hhromic It works! thanks so much

hhromic

@DarishZone thanks for the feedback. As soon as I figure out the issue I'll report back. Cheers!

hhromic

Update
I found the problem now, indeed it was an incorrect variable in the updated Makefile. I sent a pull request to upstream to fix it here.
Hopefully it gets merged soon and the build will be fixed instantly. If they take too long, I may provide a temporary patch in the RetroPie script.
Thanks for the report guys!

DarishZone

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

Update
I found the problem now, indeed it was an incorrect variable in the updated Makefile. I sent a pull request to upstream to fix it here.
Hopefully it gets merged soon and the build will be fixed instantly. If they take too long, I may provide a temporary patch in the RetroPie script.
Thanks for the report guys!

Thanx! I have to revert the lines to original ones on lr-scummvm.sh or can i leave as edited?

hhromic

@DarishZone now that you built the core successfully, yes you should revert these lines. You can do this now if you wish.

When the PR is accepted, I will also have to slightly update the scriptmodule, so you also will have to update your RetroPie-Setup . I will provide an update here in the forum with more info once things are in place.

Anyway, the new commits in scummvm don't bring any changes to the core itself so you don't need to recompile it again from the build you just did.

Edit to make sure you revert the script properly, run this:

git -C $HOME/RetroPie-Setup checkout scriptmodules/libretrocores/lr-scummvm.sh

hhromic

Update

The upstream Makefile is now fixed and the lr-scummvm scriptmodule was updated accordingly. You are all encouraged to update your RetroPie-Setup script installation if you want to re-build the core.

Speaking of which, another recent commit was merged that implements a core option to control the Mouse pointer speed when using a mouse device (in contrast to using a gamepad). The new option is named scummvm_mouse_speed and it can be found under the core options in RetroArch. Because it is a libretro option, it can be set on a per-game basis as well.

~~I haven't build the core with this new commit yet, but it should build fine. If you happen to re-compile the core, please let us know how it went.~~ Tested now, it compiles and runs fine :)

Happy point-n-clicking!

KodeCR

@hhromic Thanks for this, it's working really nicely.

I do have a small issue with the following:

Important: each game directory must contain .svm at the end of the name! This is not an "extension" but is just part of the directory's name. This is for EmulationStation to be able to launch the games directly when selecting the folder, without the need to "open" it first. Also it is useful for scraping. ES will put the images and metadata directly for each directory. In summary, ES will not consider the directory as directory but as a game.
Now, inside each game directory, you need to create a SHORT_NAME.svm file with SHORT_NAME as the content. No other .svm files should exist in the game directory!

This seems to break using the scummvm launcher to change game settings and then start the game again, i.e. start the game, scummvm menu, return to launcher, edit game, start game. This will error with "game data not found".

Looks like the reason is that scummvm uses the directory as the game data location, but strips off the .svm part!

As a solution I followed: https://github.com/libretro/scummvm/issues/94
This solution removes the .svm from the folder name and moves the .svm file out of the game data folder again, so my scummvm directory look like:

drwxrwxr-x 2 pi pi    4096 Jan 23 12:03 The Secret of Monkey Island
-rw-r--r-- 1 pi pi      64 Jan 23 11:55 The Secret of Monkey Island.svm
drwxr-xr-x 2 pi pi    4096 Jan 23 11:58 Monkey Island 2 - LeChuck's Revenge
-rw-r--r-- 1 pi pi      73 Jan 23 12:00 Monkey Island 2 - LeChuck's Revenge.svm

The contents of the .svm file are like this:

$ cat The\ Secret\ of\ Monkey\ Island.svm
-p "~/RetroPie/roms/scummvm/The Secret of Monkey Island" monkey

And I'm no longer using the rom-launcher script:

$ cat /opt/retropie/configs/scummvm/emulators.cfg
lr-scummvm = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-scummvm/scummvm_libretro.so --config /opt/retropie/configs/scummvm/retroarch.cfg %ROM%"
default = "lr-scummvm"

So far this is working well for me. Might this be a better way going forward?

hhromic

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

@hhromic Thanks for this, it's working really nicely.

Thanks for the support, I'm glad you are having fun with the core and enjoying some good ScummVM games with it.

I do have a small issue with the following:

I admit I initially haven't tested changing game settings very much, so I don't know 100% how to advise you on this one. I also recently stumbled on what you are pointing out of being able to provide the game path in the .svm files. However, I'm not very much of a fan to hardcode the game paths in these files. On the other hand, I also think it's not ideal to have the rom-launcher workaround script either.

Looks like the reason is that scummvm uses the directory as the game data location, but strips off the .svm part!

Can you describe better how you got to this conclusion?
Also can you tell me exactly what you are trying to do step by step so I can take a look when I have some time and advise better? Are these all the steps required to trigger the problem?

start any game
go to the scummvm internal menu, i.e. press START
select "return to launcher", then edit game settings
quit scummvm and re-start the game again
you receive "game data not found" error

Also, what kind of settings you are trying to change? I'm hoping in close future to actively participate in the development of the lr-scummvm core upstream so in future some things like this can be better integrated in the core itself.

Thanks for the feedback!

2Play

@hhromic Hi there!
I have tested latest lr-scummvm
joypad/controller works fine and exit also
BUT if you have mouse keybooard to navigate (no controller connected to ES), and KB configured as main controller in ES/Retroarch
Game starts fine but at first mouse click or START with keyboard assigned key Retroarch will freeze!
I kill the porcess and goes back to ES as previous mentioned reports on controller bug in the past

Hope this could also be resolved as it would be nice to use mouse keyboard with lr-scummvm

hhromic

@2Play I briefly tested the core using a mouse and a keyboard and I didn't experience any crash as you are reporting. Does your setup work on other cores that use both mouse and keyboard, for example NES/SNES with the Zapper ?
When I have a chance I will give it a try and see if I see the same.
Did you build the core recently? There is a new mouse speed option implemented some weeks ago, maybe it's causing issues. I haven't tested it yet myself.