Is there a guide somewhere to create install scripts if you can get a game to compile?

[VictimRLSH]

I'm getting pretty adept at compiling things from the Desktop, but this isn't really going to benefit other Retropie users if I can't create an install script that can run from Retropie.

Another thing I'm coming to realize is as I add more libs to my system, something that compiles on my system without hunting anything down won't readily install from a Retropie script if that library is missing. Should I write a fresh Retropie image to an SD card before I compile to see if it is missing something that a fresh install won't have, or is there an easier way?

[mitu]

I don't think there's a guide somewhere on how to write one from scratch, but you can take a look at the existing ones to see how they function. They're all Bash scripts, but they're not directly executable, they are meant to provide a set of functions that RetroPie-Setup calls when running installation/removal/configuration/etc.

Normally a scriptmodule that installs an emulator/port must have

• a header section where the name of the module is set (rp_module_id), a description (rp_module_description), a package section (rp_module_section) and - optional, but strongly recommended - a link to the license.
  There's an important header which determines on what platforms/systems the module can be installed (rp_module_flags) - RPI, x86, Odroid. Depending on how good each system is supported, the flags will determine if the module is available for installation or not for the platform where RetroPie-Setup is running.

• a set of standard named function that are called by the setup script for installation/removal/configuration. The prefix is standard and the suffix is named after the scriptmodule.
  Let's take for instance lr-beetle-psx:

  • depends_lr-beetle-psx is called to install the dependencies needed to run and build the module. You can see the packages it installs using getDepends - a helper function.

     local depends=(libvulkan-dev libgl1-mesa-dev)
     getDepends "${depends[@]}"
    

    The above could have been shortened as:

    getDepends libvulkan-dev libgl1-mesa-dev
    

  • sources_lr-beetle-pcsx - this function is called during a source installation, to download and (optionally) unpack the sources of the module

    gitPullOrClone "$md_build" https://github.com/libretro/beetle-psx-libretro.git
    

    Usually you use the gitPullOrClone helper function to clone a git/svn repository. This clones the remote repository into $md_build, which is an automatically created variable (by RetroPie-Setup), which points to:
    $HOME/RetroPie-Setup/tmp/build/<module_name>
    If the sources are not available in a source control repository, you can download an archive with the downloadAndExtract helpder function - see for instance how it's used here.

  • build_lr-beetle-psx - this function takes care of building the module, using the upstream supported build method (configure && make, cmake, autoconf, etc). Note that all the steps are run in the $md_build folder, where the sources have been downloaded.

  • install_lr-beetle-psx - it's called after the build_... step to copy the necessary files into their location in /opt/retropie. If it's an emulator- the installation is in /opt/retropie/emulators/<module>, if it's a libretro core - the installation is in /opt/retropie/libretrocores/<lr-corename>, if it's a port - the installation is in /opt/retropie/ports/<portname>.
    The files needed to be copied are set using the md_ret_files array and they should be present in the $md_build folder, otherwise you'll get an installation error.
    As an alternative using md_ret_files to indicate the files needed to install, you can run the install routine for the module, as intended by the original package (e.g. make install). See for instance how it's called for fuse.
    You can also run arbitrary commands that belong to the installation phase here, without restrictions.

    N.B. In a binary install, the installation files are extracted from archive downloaded from the RetroPie server and added automatically to the install location, under /opt/retropie.

  • configure_lr-beetle-psx - this is function called after an installation (previous steps) and it's reposible for:

    • creating the ROM/Port folder, the recommended method is to to use mkRomDir helper to create the folder.
    • adding the ROM folder to the EmulationStation, using the addSystem helper.
    • adding the emulator/port entry to the new system/port configuration using the addEmulator/addPort helper functions. This is needed so runcommand knows how to run the ROMs/Ports added. The result can be seen in the emulators.cfg file present in /opt/retropie/configs/<system>//opt/retropie/ports/<portName>.
    • (optional) adding a pre-configured settings file, with certain defaults that make sense for the platform (i.e. BIOS file location, configure where the game data is , etc.)

  • (optional) download additional if the port/emulator needs it - the shareware files for Quake/Doom/Duke3d are downloaded and copied to the correct location in this phase.

  N.B. the configure function is called both during installation and removal of the module, you can check the automatic variable $md_mode to exclude certain steps in either installation or removal. For instance tyrquake downloads and installs the shareware Quake files only during installation, there's no point in downloading them during removal.

Now, this only skims the surface of what's available in a scriptmodule and I've only described the main functions expected to be found in a scriptmodule. You can have your own functions that you can call from the main functions, but you should name them accordingly (myfunc_<scriptmodulename>).

RetroPie has a lot of helper functions which you can find here, but the best way to get accustomed to them is by looking at existing scriptmodules (and see their usage) or ask.

Remember that the scriptmodule is running as root - so take care what commands you put there. This mean that if you create folders during configuration/installation and they need to be user writable, so use the mkUserDir function instead of mkdir.

Lastly, if you're finding yourself experimenting and developing a scriptmodule, you can call any function directly from the scriptmodule, without going through RetroPie-Setup, using retropie_package.sh.

cd $HOME/RetroPie-Setup

# Install dependencies
sudo ./retropie_packages.sh <module> depends

# Install sources
sudo ./retropie_packages.sh <module> sources

# Build
sudo ./retropie_packages.sh <module> build

# etc.

This is especially useful if you need to re-run the build step repeatedly while trying different build options (to cmake, configure, make , etc.) .

[VictimRLSH]

@mitu Thanks! Definitely gives me something to work with.

I will try with something that was easier to build and would have a higher level of interest for Retropie users such as Astromenace or Valyria Tear.

[Folly]

@mitu

I used your information of this thread to make my first script module.
Nice description !, Thanks.

So now I have an almost working port of the MazeOfGaliousRemake called mog.sh

The only thing I encountered was that I used "module.sh" in these lines, at first :
(I also tried </home/pi/RetroPie-Setup/scriptmodules/ports/mog.sh>)

sudo ./retropie_packages.sh mog.sh depends

So I got this error :

No module 'mog.sh' found for platform rpi4

Seems like a beginners mistake ;-).
Quickly found that it has to be (and you don't have to add a directory) :

sudo ./retropie_packages.sh mog depends

So if anyone else is reading this, learn from my mistake.

So now I have an almost working port.

https://github.com/FollyMaddy/RetroPie-Share/blob/main/00-scriptmodules-00/ports/mog.sh

The only thing that is missing is that the binary, from the configured directory, can't find the directory's needed to run, but in fact they are in the same directory where the binary is.
So here is the binary :
/opt/retropie/ports/mog/mog-svn-20120228/mog
And it has to find files in the subdirectory's :
/opt/retropie/ports/mog/mog-svn-20120228/graphics
etc

When I run the port from the above directory it will run because I run it from the right location.

pi@raspberrypi:/opt/retropie/ports/mog/mog-svn-20120228 $ /home/pi/RetroPie/roms/ports/MazeOfGaliousRemake.sh

So how can I add "the path" in the script to make the binary find the files in the subdirectory's ?

[mitu]

@folly said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

So how can I add "the path" in the script to make the binary find the files in the subdirectory's ?

You can just change directory before launching the game, if it expects the game data/assets to be present in the running folder. Modify the launch command to do that:

#...
addPort "$md_id" "mog" "MazeOfGaliousRemake" "pushd $md_inst/mog-svn-20120228; $md_inst/mog-svn-20120228/mog"
#...

[ExarKunIv]

@mitu i have also been following this guide and looking at other scripts.

for the most part i have a understanding of whats going on. but im still a little lost on this part

function build_cdogs-sdl() {
    cmake . -DCMAKE_INSTALL_PREFIX="$md_inst" -DCDOGS_DATA_DIR="$md_inst/"
    make
    md_ret_require="$md_build/src/cdogs-sdl"
}

function install_cdogs-sdl() {
    md_ret_files=(
        'data'
        'dogfights'
        'graphics'
        'missions'
        'music'
        'sounds'
        'COPYING'
        'src/cdogs-sdl'
        'src/cdogs-sdl-editor'
    )
}

how do you find out what to put under md_ret_require= and md_ret_files=( or is it just trial and error.

im working on a script for Nblood. and there is a lot in the folder and i have no idea on what is needed and not other then the file nblood that is needed to run

thanks for any pointers

[Folly]

@mitu said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

@folly said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

So how can I add "the path" in the script to make the binary find the files in the subdirectory's ?

You can just change directory before launching the game, if it expects the game data/assets to be present in the running folder. Modify the launch command to do that:

#...
addPort "$md_id" "mog" "MazeOfGaliousRemake" "pushd $md_inst/mog-svn-20120228; $md_inst/mog-svn-20120228/mog"
#...

Great reply, it's working ! :-)
Thanks.

[Folly]

@exarkuniv

how do you find out what to put under md_ret_require= and md_ret_files=( or is it just trial and error.

If you are not sure, you can copy/configure the whole directory, just like I did.
Look at my port, it copies 1 directory with all files and subdirectory's.

[Folly]

@mitu

I am experimenting with the b-em BBC-Micro emulator fork of kilograham, which is created for the rpi-pico, but it's also possible to build this for the RPI.

This RPI build will then run almost the same as the pico build but then on the RPI.
The one I want to use is, the one that creates xbeeb and xmaster, because this will run quite good, keyboard works, and you can exit the emulator.
But you have to run it in the match-box.

I manually comiled and made configs so the xbeeb or xmaster can run in retropie.
So I wanted to make a module-script for this.

Trouble is that I have to clone multiple github repository's to compile this.
When it clones it will download far too much and when it has compiled the xbeeb and xmaster do not work.

The far too much downloading thing is the depth I think. I was thinking this should automatically do the 1 but it seems it doesn't.
Looking at the helper.sh seems I have to add the commit also if I want to manually add the depth.
I am a little bit anxious here, because is it possible that I can do something wrong that will hurt the repositories ?
I know the git command is quite powerfull and I don't want to ruin things here.

I used these commands with and without "master".
( the kilograham is missing here, I don't know if it can be shared because of the roms it contains)

gitPullOrClone "$md_build/pico-sdk" https://github.com/raspberrypi/pico-sdk.git "master"
gitPullOrClone "$md_build/pico-extras" https://github.com/raspberrypi/pico-extras.git "master"

Should it be something like :

gitPullOrClone "$md_build/pico-sdk" https://github.com/raspberrypi/pico-sdk.git "master" "fc10a97c386f65c1a44c68684fe52a56aaf50df0" "1"

Do you have a suggestion ?

[mitu]

Post your scriptmodule (or a link to it) and I'll take a look. There are a few scriptmodules that need to build from multiple git repos/sources - see for instance mupen64plus or hatari.

[Folly]

@mitu

Thanks for looking at it.

I will have look in the scripts you referring at.

Here is the link of my script :
https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/b-em-pico_pi-build.sh
It downloads more than 2Gb, but it should only download about 45 Mb.

It's still a port script which has to be converted to emu script, but basically that doesn't matter now.

[mitu]

@folly I've looked at it, but I don't see anything wrong.
If you're building for the Pi, do you still need to download & build the pico-sdk & pico-extras ? Try without them. There are a few more dependencies that are not listed (liballegro5-dev) and the build seems to stop by requiring ruby, but I don't think you'll need the PICO stuff to build the emulator.

[Folly]

@mitu

Thanks for looking at it. 😊

If you're building for the Pi, do you still need to download & build the pico-sdk & pico-extras ?

For this version, without regular menu, you do need it, otherwise it will compile the regular version with the normal menu.

Try without them.

I will try again, but this version seems to be too slow.
Perhaps it's faster in the match-box.

There are a few more dependencies that are not listed (liballegro5-dev) and the build seems to stop by requiring ruby

I will add them in the script.
I wasn't aware that this version also needs it because I already had them on my computer for compiling the regular version.

I will have a look at it once more.
Thanks for helping. 👍

[Folly]

@mitu

It took me quite some time to get it working.

I have found some strange things along the way.

I found that I can use downloadAndExtract to download github repositories.
This solution works much faster than gitPullOrClone and it seems it downloads far less data too.

The second thing I encountered was that the compiled binaries didn't work.
Strange because it manually works, so it made me wonder if it had something to do with the user who is doing it.
I tried many things, but adding sudo -u root to the cmake line does the trick.
Very strange because we already run the RetroPie-setup as root.

So I wanted to share this with you.
Do you have any idea why it doesn't make working binaries without sudo -u root ?

This is the link to the working script.
https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/b-em-pico_pi.sh

The xbeeb and the xmasterhave both demo discs in them.
The 2048 game is created by Eben Upton.
F11 is the kilograham menu
Shift + F12 boots the disc.
F12 reset
EXIT with mouse closing window

[Folly]

@mitu

I am busy with the module-script for the supermodel3 :
https://github.com/FollyMaddy/RetroPie-Share/blob/main/00-scriptmodules-00/emulators/supermodel-mechafatnick.sh

I want to improve some stuff beginning with the resolution part.
We now put most configurations inside the Supermodel.ini.
For the resolution that is a bit tricky because not every one is using the same monitor or tv.
So I made 3 predefined emulators.cfg/runcommand lines, with different resolutions, inside the script.
But I want to reduce it to 1 line.

What I would like to do is use tvservice -s or something similar and place a variable with detected video resolution inside the emulators.cfg line.

Something like this :
Supermodel-mechafatnick = "XINIT:pushd /opt/retropie/emulators/supermodel-mechafatnick;tvservice -s;./supermodel $(tvservice -s|cut bla bla bla) %ROM%"

When I do something like this, the variable isn't detected.

Do you know how I could accomplish this ?

[mitu]

@folly said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

I am busy with the module-script for the supermodel3 :
https://github.com/FollyMaddy/RetroPie-Share/blob/main/00-scriptmodules-00/emulators/supermodel-mechafatnick.sh

Terrible, terrible script.

I want to improve some stuff beginning with the resolution part.
We now put most configurations inside the Supermodel.ini.
For the resolution that is a bit tricky because not every one is using the same monitor or tv.

Use the %XRES% and %YRES% macros to get the current resolution and use it in emulators.cfg, runcommand will take care of detecting the proper resolution (tvservice is only available on a Pi) and will set the values accordingly. See how it's used in jzintv or ioquake3.

[Folly]

@mitu

Thanks for your advice.

Terrible, terrible script.

Doesn't sound very positive.
Hopefully your advice won't make it worse then.

[mitu]

Doesn't sound very positive.

Don't listen to naysayers. If your script works, then it's fine.

Hopefully your advice won't make it worse then.

You should be able to use a single emulator entry instead of passing the video res. via CLI or hardcoding it in the .ini file.

[sleve_mcdichael]

Working on creating some script modules, this thread has some good information that got me started so it seemed like a good place to post rather than starting a whole new one.

What is the significance of the CMakeLists.txt param in

cmake <params> ..

vs

cmake CMakeLists.txt <params> ..

They seem to create the same output file. However...

I had a module I was working on that failed to build when I tried to call it with retropie_packages.sh <module> build. I had already built it once, so when I tried a second time and the mkdir build && cd build wasn't able to make the dir (because it already existed), the && cd build part didn't do anything, so it tried to cmake & make from the wrong dir and, predictably, failed.

Another module, which had the CMakeLists.txt param (the above one did not), did not fail entirely. It still was not able to mkdir && cd to the build dir, but instead of failing, this one just built it right there in the main tmp/build/module folder. Is this param the reason why? Do I want to leave it in or out? Does it make a difference?

Also, it still made the same file, but it put it in the wrong place. So if I were to use retropie_packages.sh <module> install after this, it would be installing the old one from the "build" dir and not the new one I just built in the wrong place, so this isn't a solution.

I think I could begin the build function with a [[ -d build ]] && rm -rf build to remove the dir if it exists? I notice no one else does this, though. Am I just not expected to use retropie_packages.sh in this way? Or I'm supposed to manually remove the inner build dir in between uses, or...? I guess I'm looking for some hints on the proper way to write and use a scriptmodule.

[mitu]

@sleve_mcdichael said in Is there a guide somewhere to create install scripts if you can get a game to compile?:

What is the significance of the CMakeLists.txt param in ...

The correct way to invoke cmake is

cmake <PARAMS> <path_to_folder_containing_CMakeLists.txt>`

... the && cd build part didn't do anything, so it tried to cmake & make from the wrong dir and, predictably, failed.

Don't use && then, just have the 2 commands separately.

.. this one just built it right there in the main tmp/build/module folder. Do I want to leave it in or out? Does it make a difference?

No, but some programs enforce a separate build folder (out-of-tree build) so you may get an error when building directly in the source folder.

Also, it still made the same file, but it put it in the wrong place. So if I were to use retropie_packages.sh <module> install after this, it would be installing the old one from the "build" dir and not the new one I just built in the wrong place, so this isn't a solution.

If you change the build parameters, then do a cleanup first.

I think I could begin the build function with a [[ -d build ]] && rm -rf build to remove the dir if it exists?

I don't think that when building with cmake this step is necessary, so that's why is not enforced. This is an issue only when repeatedly re-building without cleaning up, so it's more of an artifact of re-trying the build with a 'dirty' state.
You should first compile the program separately - not as a scriptmodule - to get the cmake build options right, then add it to the build function and try it from retropie_packages.sh.