Updated ScummVM core based on latest sources available if you want it

[diablodiab]

I've made a new updated version of the core based on the existing libretro wrapper and the newest ScummVM sources. There are also some adjustments in the approach that completely separates the wrapper from the original source, hopefully making it easier to keep the core in sync going forward.

If this is of interest you can find it here: https://github.com/diablodiab/scummvm

The libretro-wrapper is added in one commit on top of the base source.

You are more than welcome to incorporate or use it for inspiration towards the official core if you want to. Just wanted to share.

[i30817]

Wrong again. I'm using the diablodiab core. Built it last week actually. And i have better uses of my time than playing tech support for someone that doesn't listen.

For the last time, delete your .scummvm files (the ones added in the games directories), delete your scummvm.ini file, start the core manually from 'start core', mass add all games, and either use my project to create the the .scummvm files and playlist or create them yourself only with the ids that appear between [] in the scummvm.ini file and use the manual scanner of retroarch to scan .scummvm files.

And your games will start. Including fate of atlantis.

[schmurtzm]

In fact that's me who is currently making support for you 😅 ... But it's fun to understand that finally you do the same as me by hijacking the way how the core launcher work. When you do that in fact you don't use the "game ID" but the section name of scummvm.ini (I agree that most of time they are identical but not always). However I think that the internal command line of the core still wrong because it use the path of the game (-p) which should be retrieved by scummvm itself in the scummvm.ini. Are you agree with that ?

By the way, even if it's not a mandatory at all, to give a maximum of flexibility I think that the core should accept any of the existing command line of scummvm standalone.

It's very a shame to not come to discuss to put our efforts in common because we try to solve the same problematic and have the same objectives...

[i30817]

Scummvm files must be created in the same dir as the entries for the game in the scummvm.ini file. And that's what my program does.

I mean, it seems self evident, because if you moved them, the playlist would have no clue where the game was.

And as mentioned, these cores are not 'flexible' because that would require transferring information from 'core to frontend', ie: the frontend would need to parse the scummvm.ini to find the paths.

Removing the requirement for the .scummvm files would mess up the manual scanner and the normal scanner because they have no way to recognize the games just from paths, but only from extensions and CRCs (although the normal scanner already is 'suspect' because it has a pre-set number of 'possible CRCs' for games, which is already wrong because scummvm will happily add multiple versions of the same game for languages by adding '-number' to the end of the id - use the manual scanner for scummvm and my program i guess).

The current use of .scummvm files is just to connect the games paths to the definitions on the scummvm.ini file. You can try to use 'engine:id' inside those files, but it's pointless, it doesn't make the games 'load better', the flags that scanning the game from the scummvm GUI adds are still missing if 'id' doesn't exist in scummvm.ini in the retroarch system directory, afaik. Even if you put in '--autodetect' inside those files and it worked, it wouldn't exactly be ideal because a game directory can add multiple valid games in scummvm ( different languages or 'enhanced' version for example) and you could easily end up with the 'wrong language' for instance if the game is originally spanish and you only read/understand english but the game has a english translation. In short, the step of creating the scummvm.ini file by scanning games from the scummvm GUI is necessary and using the correct ids for entries on that file in the scummvm files is also necessary.

[schmurtzm]

Globally I agree. Some remarks however :

Removing the requirement for the .scummvm files would mess up the manual scanner ...

I don't ask to remove .scummvm files ;)

the frontend would need to parse the scummvm.ini to find the paths.

• It's already working like that : if you just put the target name (= the "scummvm.ini section name" that appear between []) in the command line (and not the -p) it is enough to run the game without modifying anything in the core. You don't need the -p because the scummvm part of the code already reading the corresponding path= in the scummvm.ini. It's interesting because it means that you can put your .scummvm file anywhere and potentially separate it from the games folders.
• be obliged to put .scummvm has one drawback : it can make the scan long due to certain games has numerous subfolders and files

You can try to use 'engine:id' inside those files, but it's pointless

Normally if you indicate a -p (which is always used like this in the current core because it is designed to use 'engine:id' !) you have to use 'engine:id' as documented on ScummVM website :

=========== screenshot of ScummVM documentation : ===============

==========================

What you do currently is that : scummvm -p <path to game files> <target> which is not really supported by ScummVM : I think that the -p is skipped and overrided by the path= value from scummvm.ini. Agree ?

EDIT : no the -p is not skipped but if we don't mention it, the core will look in scummvm.ini

[asciibeats]

I created an AUR package for my fellow Arch Linux users,

[diablodiab]

Sure, make that repo, then transfer it over to me so I can move it to the libretro org. From there, I will give you admin access over it as well. So you won't lose anything in the process. And we'll have an easier time gathering contributors that can contribute to it.

Done :)

[spleen1981]

I think the "libretro backend" structure (used in the legacy core and in @diablodiab's one as well) makes sense only if the intent is to merge with the project upstream, which I don't think is the case here, otherwise it's just a useless complication.

Starting from the legacy core source, I've reorganized from scratch and improved the code here ScummVM mainline libretro core

• ScummVM main repo is included as a submodule. To sync the libretro core it should be sufficient to update the submodule and build, unless modifications to core source/makefiles are needed due to changes upstream.
• No patch is applied to the submodule
• Submodule updates are committed following ScummVM official releases. First three fields of core tags are relevant to upstream ScummVM version, last is libretro core revision (e.g. v2.6.1.1 is ScummVM 2.6.1, core revision 1).

Makefiles have been reworked and refactored as needed:

• Available engines are retrieved and added automatically at build time from ScummVM submodule source code, no need for manual modifications anymore
• Datafiles and themes bundle (scummvm.zip) and core.info files are created automatically at build time based on current submodule source, no need for manual modifications anymore
• All hard-coded dependencies have been turned to submodules from the proper libretro repository (libretro-deps)
• Hard coded libreretro-common is turned to submodule as well.
• Various other fixes and refactorings

Added also a couple of useful options:

• Virtual keyboard toggle ("select" on retropad). Files bundled in scummvm.zip are needed for this to work.
• D-pad acceleration time

Still lot of cleaning/improvements to do, including better input mapping options, games identification without need for .scummvm files, and direct use of upstream configure script. Those will be investigated later.

Couple of commits have been taken from @diablodiab repo and forks (hence all improvements in those are merged here as well), but following modifications were too heavy to be handled through PRs to the said repos, and needed a separated one.

This core is currently merged in Lakka master and RetroArch Kodi add-on for CoreELEC, feel free to submit PRs as needed.

[hizzlekizzle]

@spleen1981 any chance you're on discord? @LibretroAdmin was hoping to talk to you a bit about how we can get it integrated. I agree with your points about maintainability with the submodule strategy.

[spleen1981]

yes I'm there - spleen1981#3705