Optimize Port Launchers!

IMPORTANT TIP:
On my GitHub I host a small repo with SystemR36 prepared/cleaned/stripped launcher scripts for several games I’ve tested. Do note that I will NOT endlessly add more and more titles to that repository, but you can use them to get an idea on how to do it. You can find the ‘pre-stripped-launchers’ here [LINK WILL FOLLOW LATER!]

Optimization Settings In SystemR36
As most of you probably already know (and what is likely the reason you’ve chosen to use my distro), SystemR36 basically gives you full control over all three governors, zram, swap, thermal throttling and even if EmulationStation stays active (in the background) when you start a game. You can even configure this per game by pressing [SELECT] when you’ve highlighted a game, rom, port etc and then scrolling down to ‘EDIT THIS GAME’S METADATA’.

There you can configure if you want it to use PulseAudio, what governor modes to use, which CPU Scheduling priority, swap, zram etc. You can even choose to run it as sudo (NOT recommended in most cases though!).

But what is the use of all those functions if you for example have a crappy unvetted LLM generated launcher which just bluntly creates a swap file in the game it’s directory (tearing through your SD-Card!), bluntly setting governors directly etc, WITHOUT you having any control over it?

THAT is something I personally don’t accept from a launcher. There is a reason I use Linux: I want to control what my system does, not some random software or (game) launcher.

Therefor I STRONGLY recommend to ‘clean up’ launchers you just randomly downloaded from the internet for your downloaded PC, Android, XBOX etc whatever ports, to not only get the maximum control and performance out of both your R36 and SystemR36, but also to keep your hardware and storage cards healthy

In this section I’m going over some examples on how you can optimize your own Launcher scripts for use on SystemR36, this can either be for your own games you’re making, but also edits to ports you’ve downloaded.

IMPORTANT NOTE: If you are developing/porting a game to also run on dozens of other distro’s, then you obviously should NOT strip it this extensively because then it is NOT portable anymore! HOWEVER! You can if you like implement proper SystemR36 support for the additional features and control it offers to users by applying these techniques 😊

In this document I’m assuming you will only be fine tuning/cleaning the launchers for use on your own SystemR36 installation to squeeze every bit out of your R36 😊

Logging only when YOU want it to log

Like I already explained on the main page, extensive logging can cause several performance issues. Without going too much into the technical details on how and why this happens, you could for example have micro stutters, audio glitches (in extremer cases), it can cause FPS drops and worst of all: it WILL wear down your SD-Card significantly faster.

Making Logging optional (user choice)
In the PowerMenu of SystemR36 you have the following option:
[Settings] -> [Developer & Debugging Options] -> Allow (Port) Games Logging (> log.txt)

Where you can choose to set it to either Yes or No, where no is the default. SystemR36 will create a ‘lock-file’ at:
/var/lock/allowgamelogging.flag when you set this option to Yes. This does NOT automatically make ANY game log for you, but it gives you a “status file” to detect IF you want to log for that game.

Why is this important? Well because in lots of those ‘generated launcher scripts’ you will often see something like:

LOG="$GAMEDIR/logs/log.log"
exec > >(tee -a "$LOG") 2>&1

Those two lines? Basically mean: “Dump ANYTHING the game outputs to log.txt on the SD-Card in the game folder.”

So if you want to prevent that you can now (when using SystemR36) replace a lines like that with:

if [ -f /var/lock/allowgamelogging.flag ]; then
    LOG="$GAMEDIR/logs/log.log"
    exec > >(tee -a "$LOG") 2>&1
fi

If you noticed the two bold lines (the top line and fi), then you also noticed the /var/lock…… part right? That part basically means that if that file (/var/lock/allowgamelogging.flag) exists on the system, that logging is allowed and thus we sell .sh launcher script that it should start logging. If the file isn’t there? Then we don’t start logging when the game/port starts 😊

IMPORTANT NOTE(S):
Enabling/Disabling logging with this PowerMenu option should be done BEFORE starting a game/port! You CAN NOT suddenly start/stop logging mid-game. That is simply put just not possible for most games and impossible to make universal 😉.

Make sure when ‘encapsulating’ the log function(s) in an launcher, that it doesn’t crash/flip-out in other parts of the launcher script because some scripts for example use a variable like the LOG=”$GAMEDIR/logs/log.log” also in other sections of the script. It might be a bit challenging with some messy scripts to clean them up, and I really wish I could make it easier for you, but lots of those LLM generated scripts are just sooooo insanely random and long that I unfortunately can’t make a ‘universal how to’ for every one. I have seriously seen a couple “launcher scripts” which where over 1100 lines! A normal HIGHLY compatible launcher should be less than a quarter of that!

[MORE OPTIMIZATION/LAUNCHER CLEANUP TOPICS WILL FOLLOW LATER!]