Suggestions for ports #2

sleve_mcdichael

function remove_minecraft() {

quicksilver

@sleve_mcdichael d'oh how'd I miss that

ExarKunIv

@quicksilver nicely done. I'll add it to the main repo.

retropi19

@exarkuniv said in Suggestions for ports #2:

@quicksilver nicely done. I'll add it to the main repo.

hi
When you will add the avp i gave you and the other things like
thunderbird,vlc etc??

ExarKunIv

@retropi19 I did not forget about AVP. But I did forget the others you gave me.
I came across them the other day.
Just been busy. I'll be adding them in a few days

ExarKunIv

Added new scripts to my Github

audacity
epiphany-browser
gtkboard
kraptor
kweb
librecad
libreoffice
mixx
mypaint
piegalaxy
putty
thunderbird
videolan

forgot about

supertuxkart

enjoy all

sleve_mcdichael

@quicksilver said in Suggestions for ports #2:

supertuxkart

[ -f "$md_inst/supertuxkart" ]] && rm -rf "$md_inst/"*

What is this for? It looks like it's leftover from the Minecraft scriptmodule you adapted(?) this from, where it looks like it is meant to remove a previous compiled version, which now won't be replaced because the install module has been changed to use an apt package instead. This seems like a pretty unique situation, is this really applicable here?

Also taking a hint from the official supertux (sans "kart") module, there is:

function _update_hook_supertux() {
    # to show as installed in retropie-setup 4.x
    hasPackage supertux && mkdir -p "$md_inst"
}

We should probably add a similar function to, as it says, "show as installed in retropie-setup."

Do we really need to mess about with $md_inst/supertuxkart.sh? In the Minecraft module, this script does more than just launch the game. Can we just make the addPort command "XINIT:/usr/games/supertuxkart" and do away with the extra script in $md_inst?

You can add moveConfigDir for network backup of saves and configs:

moveConfigDir "$home/.config/supertuxkart" "$md_conf_root/supertuxkart"

If this is for Pi 4 only you'll want to change the module flags:

rp_module_flags="!all rpi4"

...or something else that might allow higher-end devices too (I'm not fluent in module flags. For example I don't even know what "mali" is. But why would this not run on x86?)

I haven't tested this yet. Can probably try tomorrow. Does it run well on RPi4?

#!/usr/bin/env bash
 
# This file is part of The RetroPie Project
#
# The RetroPie Project is the legal property of its developers, whose names are
# too numerous to list here. Please refer to the COPYRIGHT.md file distributed with this source.
#
# See the LICENSE.md file at the top-level directory of this distribution and
# at https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/master/LICENSE.md
#

rp_module_id="supertuxkart"
rp_module_desc="SuperTuxKart - a free kart-racing game inspired by the Mario Kart series"
rp_module_licence="GPL3 https://sourceforge.net/p/supertuxkart/code/HEAD/tree/main/trunk/COPYING?format=raw"
rp_module_section="exp"
rp_module_flags="!all rpi4"

function _update_hook_supertuxkart() {
    # to show as installed in retropie-setup 4.x
    hasPackage supertuxkart && mkdir -p "$md_inst"
}

function depends_supertuxkart() {
    getDepends xorg
}

function install_bin_supertuxkart() {
    aptInstall supertuxkart
}

function remove_supertuxkart() {
    aptRemove supertuxkart
}

function configure_supertuxkart() {
    addPort "$md_id" "supertuxkart" "SuperTuxKart" "XINIT:/usr/games/supertuxkart"
    moveConfigDir "$home/.config/supertuxkart" "$md_conf_root/supertuxkart"
}

quicksilver

@sleve_mcdichael I'm still trying to decipher what all the different functions do so it's certainly possible my first attempt at a script module has things that don't make sense. So I appreciate your feedback!

I would assume that the game would run on x86 as that's probably it's native environment. However I don't have a way to test that. Performance is good on my pi 4.

ExarKunIv

@quicksilver im in the same boat with the flags, all i know that if a x86 flag is there it will not install on the Pi. that is all i have figured out, lol

retropi19

@exarkuniv thanks for adding my scripts
Will you add also the log2ram as a script or to be installed automatic with your extras??

Also can you add george box86 scripts?

git clone --branch emulator https://github.com/GeorgeMcMullen/rp-box86wine /home/pi/RetroPie-Setup/ext/rp-box86wineemu/

sleve_mcdichael

Well I'm somewhat fluent, I guess. I don't know what all the different individual flags mean but I know basically how the function works.

For starters, the exclamation point ("!") is a negator symbol, it means "not." You can exclude certain platforms this way. "!mali !x86" for example means "not mali, and not x86; anything else is okay." As I said before I'm not sure what "mali" is; "!x86" would be used in cases like Minecraft: Pi Edition where the software is based entirely around ARM architecture and would not work on a PC, not because it doesn't have the resources, but because it doesn't speak the language.

Alternatively, you can restrict it to certain platforms, for example "!all rpi4"; !all disables it everywhere and then rpi4 re-enables it on RPi4 only.

"" (or, simply not setting an rp_module_flags= variable) will enable a module on all platforms, while using "!all" will disable it, everywhere.

It doesn't make much sense to just copy the flags from another module that's using different software; if you don't know what ones to use, start with either "" or "!all" and then either disable or enable it on individual platforms as you are able to test.

It looks like we can see the system.sh function get_platform() for a list of the platforms and their flags.

sleve_mcdichael

Oh. It's 500 MB large. This might take a little while... :)

sleve_mcdichael

@sleve_mcdichael said in Suggestions for ports #2:

function _update_hook_supertuxkart() {
    # to show as installed in retropie-setup 4.x
    hasPackage supertuxkart && mkdir -p "$md_inst"
}

This doesn't appear to be necessary, I commented it out before installing and it still shows as "installed," with the $md_inst dir and retropie.pkg created inside of it.

sleve_mcdichael

SuperTuxKart, the module worked fine, even if the game itself was a bit dodgy on my hardware. First, it gives me a warning about "OpenGL version appears to be too old (requires 3.1 or better)", but it runs anyway. Full gamepad support out the box. Track Oliver's Math Class ran at a smooth 45-60 fps for the entire race (staying near the high end most of the time) on the default "level 3" graphic settings.

But it went downhill from there. Framerate got pretty bad on Cocoa Temple, range 11-27 fps. Turning video settings to "custom" and disabling literally everything (well, the one thing that was still left from the minimal "level 1" settings) improved that slightly, but still pretty bad (12-35). Most of the race is spent in the lower-mid range of those spreads.

It spiked my temperature pretty quickly too, not enough to throttle it but it got within about 6C, even higher than N64 does, and I only played it for a few minutes.

Looks like it could be a great game if the system can handle it, but it might still be a bit too meaty for RPi4.

These next are not likely performance-related:

Sometimes when I finish (well, fail) a race in "story" mode, it will kick me back to the Race Settings screen and then I'll be back in "single-player."

One time I paused it and walked away for a few minutes & when I came back the gamepad wouldn't respond, only the keyboard.

sleve_mcdichael

I ended up removing it. The 600-some-odd MB of supertuxkart-data et al did not go with it.

Investigating, it seems autoremove is only invoked in the getDepends function* in helpers.sh, and not in aptRemove.

I see it's also used in a couple other places in scriptmodules/supplementary so I would imagine it's okay but I would still ask, @mitu, is this "safe" to put in a "regular" scriptmodule, and the right way to do this?

function remove_supertuxkart() {
    aptRemove supertuxkart
    apt-get autoremove -y
}

*(and even then, I guess only if you invoke it with ./retropie_packages.sh {package} depends remove because xorg and it's depends were not removed, either. But at least they're not 600MB.)

Drdave79

@ExarKunIv Anyone else install Shadow Warrior and the keyboard doesn't respond? All of my other games under ports work fine. But SW either freezes or has no controllability. It actually works ok under DOS GAMES though. I just have a problem with the scroll lock. So I'd rather have it working under ports.

Thank you.

ecto

@Drdave79 Make sure, that you don't enable fullscreen mode. For some reason this happens because the game looses focus. It should work in windowed mode.
You probably have to either delete (careful: make a backup) sw.cfg(or whatever it's called) or edit it's content to enable windowed mode. I don't remember where it's stored, though. Sorry.

ExarKunIv

@Drdave79 @ecto is correct on that, but i will go back and take a better look.

Drdave79

@ecto Deleting the .cfg file didn't do anything. These are the only options for screen mode in the .cfg file

;ScreenMode
; - Chained - 0
; - Vesa 2.0 - 1
; - Screen Buffered - 2
; - Tseng optimized - 3
; - Paradise optimized - 4
; - S3 optimized - 5
; - RedBlue Stereo - 7
; - Crystal Eyes - 6
;
;ScreenWidth passed to engine
;
;ScreenHeight passed to engine
;
;
ScreenMode = 1
ScreenWidth = 640
ScreenHeight = 480

Drdave79

@ExarKunIv I tried a different copy of the game and got the following error on launch:

There was a problem initializing the Build engine: Failed to load PALETTE.DAT!

The other version loads at least, but frozen on game menu.