lr-scummvm: request for comments and testing

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.

Fabien

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

There is a new mouse speed option implemented some weeks ago ...

This is great news! :D However, I've updated the core but I can't find the option?

hhromic

@Fabien where are you looking for the option? This is a libretro core option, not a ScummVM option (GUI Menu), so you should look for it in the RetroArch Options menu (HOTKEY + X). Here is a list of all the options you should find there (you are looking for mouse_speed):

{ "scummvm_gamepad_cursor_speed", "Gamepad Cursor Speed; 1.0|1.5|2.0|2.5|3.0|0.25|0.5|0.75" },
{ "scummvm_analog_response", "Analog Cursor Response; linear|cubic" },
{ "scummvm_analog_deadzone", "Analog Deadzone (percent); 15|20|25|30|0|5|10" },
{ "scummvm_mouse_speed", "Mouse Speed; 1.0|1.25|1.5|1.75|2.0|2.5|3.0|0.05|0.1|0.15|0.2|0.25|0.3|0.35|0.4|0.45|0.5|0.6|0.7|0.8|0.9" },
{ "scummvm_speed_hack", "Speed Hack (Restart); disabled|enabled" },

Fabien

@hhromic Thanks for clarifying! I've found the option. :)

But it only works in Retropie. On my Windows PC the option is still missing - even after updating the core. Is this a Retropie exclusive function?

hhromic

@Fabien no, is not exclusive to RetroPie.
It is not yet on Windows (or Mac) because currently the core has a build error on the official libretro buildbot. I already submitted a fix here, but you will have to wait for them to merge this PR for the core to be updated again in their system.
Be patient and you should see the core updated for Windows hopefully soon.

RetroPie compiles the core directly from the repository, not their buildbot, that's why it's available here first :)

KodeCR

However, I'm not very much of a fan to hardcode the game paths in these files.

Me neither, maybe we can use relative paths (i.e. -p "./The Secret of Monkey Island") if we add something like (untested):

#!/bin/bash
rompath="${3%/*}"
cd "$rompath"

in runcommand-onstart.sh

Also can you tell me exactly what you are trying to do step by step

I'm doing step 1,2,3 and then instead of quiting scummvm/retroarch I try to start the game from the launcher, after which I get the "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!
Can you describe better how you got to this conclusion?

In the scummvm launcher if you go to the tab that has the game data location, it's missing the .svm there. I admit that's not definite, but suspicious.

Also, what kind of settings you are trying to change?

Just per game midi settings, and playing around really.

Hope that helps.

hhromic

@KodeCR thanks for the feedback, will take a look when I have some time in coming weeks on how to best approach this. Will report back!