Adventuregamestudio (AGS) Scriptmodule Updates

windg

I have some heavy AGS games( like Technobabylon) and i have try them in both ags and scummvm. With ags emulator, games running faster than scummvm, especially in RPi3

Lolonois

@mitu thanks for the nudges. I updated the scriptmodule in my feature branch.

Re: Config
I updated the script accordingly. Turned out that with the XDG_DATA_HOME environment variable the configuration directory can be set without using symlinks.

Re: SDL_Sound
The SDL_sound is now statically linked. Thanks for that hint, made things easier.

Re: X11
I had not the impression that there is a dependency to X11. Seems SDL2 is all what it needed. However, I did test only a few games.

Re: Scraper
I can only speak for Skyskraper. Platform ags is not supported currently. However, I symlinked a none used platform on my setup (gc to ags) and scraped with platform pc and with source mobygames which gave me some hits. I exported the hits from the pc cache of Skyskraper and then imported them into gc respectively ags. Awkward workaround but it did the trick.
The file/folder format is to make Emulationstation and to encapsulate AGS files (because every AGS game uses audio.vox, speech.vox, aso.)

Re: ScummVM
The AGS maintainers follow quite strictly the upstream of AGS, but currently there are two known bugs [1,2] pending which are only solved upstream. However, I assume in a few weeks ScummVM will sync with AGS upstream.

Attn.: These are containing spoiler for the games.
[1] https://bugs.scummvm.org/ticket/14197
[2] https://bugs.scummvm.org/ticket/13724

Lolonois

@windg thanks for the info. Makes sense to me. Can you tell if you are using the software renderer or OpenGL (see: --gfxdriverswitch of ags)?

windg

@Lolonois I am using the default setting, is set to software.

mitu

OK, I've taken a look at the scrips - thanks for the changes.

I updated the script accordingly. Turned out that with the XDG_DATA_HOME environment variable the configuration directory can be set without using symlinks.

OK, but our approach is usually the use a symlink to $configdir. This way it's easier for the user to access it (via shares) and the application works like in a normal installation (thus all application documentation still applies w.r.t. config folders).

Re: SDL_Sound
The SDL_sound is now statically linked. Thanks for that hint, made things easier.

You also added statically build options for the other libraries added in depends, that doesn't seem right. And for sure we'd want ags to use the system's SDL2 - this way our local SDL2 patches are applied (resolution switching, DRM/KMS support).

Re: Scraper

To be honest, since we already have game.exe and game/ folder in ags, I don't see the point in adding another (empty) game.exe underneath the game folder.

Other comments for the scriptmodule:

don't use make -j$(nproc), RetroPie-Setup already takes care of that via MAKEFLAS.
what's the point of creating an empty acsetup.cfg file ? Is it required by ags ?

Lolonois

Cleaned up a bit. Thanks again.

Using the moveConfigDir approach
Reviewed the static linked libs again and simplified cmake defines
No more default/dummy acsetup.cfg (was thought as convenience, is not mandatory for ags to launch successfully)
Removed uneeded parts from launcher, removed make -j flag

Maybe I got the cmake options wrong or I misunderstood your intention, but ldd shows Freetype, SDL2, Ogg, Vorbis and Theora libs as dynamically linked. Or are you relating to libaldmb and liballegro?

These are the configuration options cmake reports on build:

[...]
------- AGS dependencies options -------
 AGS_USE_LOCAL_ALL_LIBRARIES: ON
 AGS_USE_LOCAL_SDL2: ON
 AGS_USE_LOCAL_SDL2_SOUND: OFF
 AGS_USE_LOCAL_OGG: ON
 AGS_USE_LOCAL_THEORA: ON
 AGS_USE_LOCAL_VORBIS: ON
[...]

Having an empty game.exe sibling to game/ and the real game executable in game/ (must not match the parent folder) is mainly to be able to have a flat gamelist in ES. Without the empty .../roms/ags/game.exe one would have to navigate into the gamefolder game/first and then launch an exe from there. IIRC it is a limitation of ES that it expects roms to be directly in the system's subfolder while maintaining a flat list game list at the same time.

mitu

Maybe I got the cmake options wrong or I misunderstood your intention, but ldd shows Freetype, SDL2, Ogg, Vorbis and Theora libs as dynamically linked. Or are you relating to libaldmb and liballegro?

I think I may have the meaning of the option wrong, the way it's right now is fine.

Having an empty game.exe sibling to game/ and the real game executable in game/ (must not match the parent folder) is mainly to be able to have a flat gamelist in ES. Without the empty .../roms/ags/game.exe one would have to navigate into the gamefolder game/first and then launch an exe from there. IIRC it is a limitation of ES that it expects roms to be directly in the system's subfolder while maintaining a flat list game list at the same time.

You're right, it's fine. I was under the impression (following the docs) that we already have the configuration with the .exe in the ags folder already covered.

A few more notes on the scriptmodule:

don't use [pushd|popd] || exit 1, we don't use it like this. If the folder creation was problematic, make would fail and the build would be failed also.
there's no point in creating the launcher in the ags folder. The +Start <Emu>.sh construct is for the cases where the emulator can be launched without content, either for configuration (i.e. scummvm) or for direct launch (i.e. dosbox).
Create the launch in $md_inst and don't run the creation if "$md_mode" == "remove", there's no point in adding it when the emulator is removed (configure runs also in the removal phase).
the launcher doesn't test if the game folder exists - perhaps it should do that ? If there are games which can run from the .exe only and there's sibling game folder, then the $ROM var from the launcher would point to a non-existing folder and - probably - the emulator will throw an error.

Lolonois

I ironed out the issues you mentioned, thanks again for the advise.

I will document these scriptmodule design notes for the wiki in the next days.

BuZz

@Lolonois Thanks for your efforts on this.

mitu

@Lolonois said in Adventuregamestudio (AGS) Scriptmodule Updates:

I ironed out the issues you mentioned, thanks again for the advise.

Look ok. One final niggle - module specific functions should be suffixed with the module name, to prevent name collisions. So create_launcher should be create_launcher_ags. We also prefer that local utility functions to be prefixed with _ (i.e. _create_launcher_ags).
I think it's enough to submit the changes as a PR.