Run Spelunky and other Android Game Maker games on Pi5 / arm64
-
With the advent of the Pi5 and the increased popularity of arm64 bit the
droidports
(Game Maker Loader) did no longer compile and run.I provided a solution for the
gmloader.sh
scriptmodule which crosscompiles on the Pi5/arm64 a 32bit binary of gmloader.In case you missed Spelunky: https://www.polygon.com/2019/11/8/20953893/spelunky-most-important-game-of-the-decade-2010
I have tested it on a Rpi5, RaspiOS Lite 64bit with RetroPie-Setup -> Basic Install and the dev version of EmulationStation and also on a more crowded installation which uses some Retroarch emulators.
Please test and report back.
Notes:
- Be aware that the setting
kernel=kernel8.img
is mandatory in/boot/firmware/config.txt
. - Make sure to have a full backup of your current setup in the rare case something goes foobar.
Some Qs to the community:
-
As several extra armhf packages are installed, what is the "RetroPie way" for the remove function (
remove_gmloader()
): E.g. Remove them and also run aapt autoremove
? -
The scriptmodule pulls in the RetroPie compiled SDL2 libs, namely
libsdl2-2.0-0_2.26.3+1rpi_armhf.deb
andlibsdl2-dev_2.26.3+1rpi_armhf.deb
. I assume they are provided for a reason, or will the upstream packages do as well?
- Be aware that the setting
-
-
@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:
As several extra armhf packages are installed, what is the "RetroPie way" for the remove function (remove_gmloader()): E.g. Remove them and also run a apt autoremove?
In general, there's no removal of dependencies on package removal, since we can't know if that package is also used elsewhere.
The scriptmodule pulls in the RetroPie compiled SDL2 libs, namely libsdl2-2.0-0_2.26.3+1rpi_armhf.deb and libsdl2-dev_2.26.3+1rpi_armhf.deb. I assume they are provided for a reason, or will the upstream packages do as well?
Not sure what you mean, are you asking why your scriptmodule pulls some dependencies ? Isn't this coded in your scriptmodule already ?
-
@mitu said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:
[remove function of scriptmodule]
In general, there's no removal of dependencies on package removal, since we can't know if that package is also used elsewhere.
Ok. Makes sense.
[SDL2 libs from RetroPie vs Upstream]
Not sure what you mean, are you asking why your scriptmodule pulls some dependencies ? Isn't this coded in your scriptmodule already ?
It puzzles me as on a Pi4 there is the SDL2 lib package from RetroPie set on hold.
On a Pi5 with 64bit RaspiOS AFAIR the SDL2 scriptmodule installs also the 2.26.3+1rpi_arm64 (from sources). Thus I assumed this RetroPie SDL2 version is needed also on the Pi5/arm64 for some reason.My question is like this then:
When a RetroPie SDL2 lib is found on a Pi5/arm64 do also install the counterpart on armhf?
-or-
Whatever version of SDL2 is installed (or even if it is absent), replace it with the one from the upstream package for arm64 and armhf? -
@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:
On a Pi5 with 64bit RaspiOS AFAIR the SDL2 scriptmodule installs also the 2.26.3+1rpi_arm64 (from sources). Thus I assumed this RetroPie SDL2 version is needed also on the Pi5/arm64 for some reason.
On non-X11 platforms, RetroPie always tries to install its custom SDL2 version. You can bypass this if you want, but you'll be missing the
kms
bits which allowruncommand
's resolution settings to propagate to SDL2 applications (emulators).
You can bypass this by settingown_sdl2=0
inretropie.cfg
.My question is like this then:
When a RetroPie SDL2 lib is found on a Pi5/arm64 do also install the counterpart on armhf?Technically I don't think you'd be able to have different versions, one for each arch. But things are no so simple, see this issue and the discussion around it.
-or-
Whatever version of SDL2 is installed (or even if it is absent), replace it with the one from the upstream package for arm64 and armhf?You override the install flag (
own_sdl2
) so you can use the distro's packages, but with the caveats explained above. -
The gmloader uses the RP SDL2 libs and not the upstream ones.
I managed to get it properly working when either the RP SDL2 (arm64) libs are present or absent when installing gmloader. And also vice-versa.
However I noticed that the idempotence of the
sdl2.sh
scriptmodule is no longer given with multiarch and thelibsdl2-2.0-0:armhf
installed, e.g. it derails when run again after gmloader is installed with this message:Unpacking libsdl2-2.0-0:arm64 (2.26.3+1rpi) ... dpkg: error processing archive libsdl2-2.0-0_2.26.3+1rpi_arm64.deb (--install): trying to overwrite shared '/usr/share/doc/libsdl2-2.0-0/changelog.gz', which is different from other instances of package libsdl2-2.0-0:arm64
If I add these flag to
dpkg
the idempotence is restored with multiarch.diff --git a/scriptmodules/supplementary/sdl2.sh b/scriptmodules/supplementary/sdl2.sh index 861977c..ba7be8e 100644 --- a/scriptmodules/supplementary/sdl2.sh +++ b/scriptmodules/supplementary/sdl2.sh @@ -138,7 +138,7 @@ function remove_old_sdl2() { function install_sdl2() { remove_old_sdl2 # if the packages don't install completely due to missing dependencies the apt-get -y -f install will correct it - if ! dpkg -i libsdl2-2.0-0_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb libsdl2-dev_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb; then + if ! dpkg -i -E --force-overwrite libsdl2-2.0-0_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb libsdl2-dev_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb; then apt-get -y -f --no-install-recommends install fi echo "libsdl2-dev hold" | dpkg --set-selections
The
--force-overwrite
would overwritechangelog.gz
andcopyright
in the/usr/share/libsdl2-2.0-0
folder.Would it be ok to file a PR for the patch?
-
@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:
Would it be ok to file a PR for the patch?
I don't think so. Brute forcing is not a solution, but merely a workaround. How is Debian dealing with it ?
EDIT: Try adding
Multi-Arch: same
to the
control
file for the package (e.g. like https://salsa.debian.org/sdl-team/libsdl2/-/blob/debian/latest/debian/control?ref_type=heads#L55) and see if the multi-arch installation goes through without conflict errors. -
@mitu Thanks. I have seen this flag. And it is unchanged from upstream. This is why I am scratching my head.
In the debian package it states (which gmloader downloads and installs):
$ LANG=C dpkg-deb -I libsdl2-2.0-0_2.26.3+1rpi_armhf.deb new Debian package, version 2.0. size 445284 bytes: control archive=1040 bytes. 657 bytes, 18 lines control 527 bytes, 7 lines md5sums 28 bytes, 1 lines shlibs 68 bytes, 2 lines triggers Package: libsdl2-2.0-0 Source: libsdl2 Version: 2.26.3+1rpi Architecture: armhf Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org> Installed-Size: 1484 Depends: libc6 (>= 2.34), libudev1, libdbus-1-3 Conflicts: libsdl-1.3-0 Replaces: libsdl-1.3-0 Section: libs Priority: optional Multi-Arch: same [...]
As well as in the
sdl2.sh
scriptmodule thecontrol
file is not altered in this aspect and usesMulti-Arch: same
from upstream. The (pre)installed version reflects this also:$ aptitude show libsdl2-2.0-0:arm64=2.26.3+1rpi Package: libsdl2-2.0-0 Version: 2.26.3+1rpi State: installed Automatically installed: no Multi-Arch: same Priority: optional Section: libs Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org> Architecture: arm64 Uncompressed Size: 1,834 k Depends: libc6 (>= 2.34), libudev1, libdbus-1-3 Conflicts: libsdl-1.3-0 Breaks: libsdl2-2.0-0:armhf (!= 2.26.3+1rpi) Replaces: libsdl-1.3-0, libsdl2-2.0-0:armhf (< 2.26.3+1rpi) Description: Simple DirectMedia Layer SDL is a library that allows programs portable low level access to a video framebuffer, audio output, mouse, and keyboard. This package contains the shared library, compiled with X11 graphics drivers and OSS, ALSA and PulseAudio sound drivers. Homepage: http://www.libsdl.org/ Tags: role::shared-lib
The only thing which may be odd is the
Replaces: libsdl-1.3-0, libsdl2-2.0-0:armhf (< 2.26.3+1rpi)
. But as the version comparator for libsdl2-2.0-0 is "less" than and not "less or equal" it should not have an effect.(NB: the same can be seen on the armhf package:
$ aptitude show libsdl2-2.0-0:armhf=2.26.3+1rpi Package: libsdl2-2.0-0:armhf Version: 2.26.3+1rpi State: installed [held] Automatically installed: no Multi-Arch: same Priority: optional Section: libs Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org> Architecture: armhf Uncompressed Size: 1,520 k Depends: libc6:armhf (>= 2.34), libudev1:armhf, libdbus-1-3:armhf Conflicts: libsdl-1.3-0 Breaks: libsdl2-2.0-0 (!= 2.26.3+1rpi) Replaces: libsdl-1.3-0, libsdl2-2.0-0 (< 2.26.3+1rpi) [...]
-
@Lolonois I'll take a look to see what can be done for the packages to be installable in this - multi-arch - scenario. Upstream packages have the same files included, but there's no conflict (I assume, haven't tried it so far).
-
Thanks. But handle it with lower priority, as the gmloader is not a official RetroPie package and this issue only shows when sdl2 from RP is present before gmloader is installed and then it is tried to reinstall the sdl2 after gmloader is installed.
Workaround for anyone stumbles about this:
- Remove libsdl2-2.0-0:armhf.
sudo apt remove libsdl2-2.0-0:armhf
- Remove sdl2:
sudo RetroPie-Package/retropie_packages.sh sdl2 remove
- Remove potential leftovers:
sudo rm -f /usr/share/doc/libsdl2-2.0-0/copyright /usr/share/doc/libsdl2-2.0-0/changelog.gz
- Install sdl2 again:
sudo RetroPie-Package/retropie_packages.sh sdl2
- Run gmloader script again to get back libsdl2-2.0-0:armhf.
sudo RetroPie-Package/retropie_packages.sh gmloader
- Remove libsdl2-2.0-0:armhf.
-
@Lolonois I've tried to see where is the problem on an multi-arch installation and check whether this is a packaging issue for the SDL2 packages we create. From what I can see, the packaging is ok, the thing is you need to have both packages at the exact same version and built using the same source.
I've build - on a clean env - 2 arch packages from RetroPie's SDL2 sources and they can be co-installed on the same system:
mitu@host:~/src/sdl.mine[cross]$ dpkg --print-architecture amd64 mitu@host:~/src/sdl.mine[cross]$ uname -r 6.10.11-amd64 mitu@host:~/src/sdl.mine[cross]$ uname -m x86_64 mitu@host:~/src/sdl.mine[cross]$ dpkg --print-architecture amd64 mitu@host:~/src/sdl.mine[cross]$ dpkg --print-foreign-architectures i386 mitu@rockman:~/src/sdl.mine[cross]$ dpkg -l | grep libsdl2-2.0-0 ii libsdl2-2.0-0:amd64 2.30.8+rpi6 amd64 Simple DirectMedia Layer ii libsdl2-2.0-0:i386 2.30.8+rpi6 i386 Simple DirectMedia Layer
It was easier to set-up a cross-build env on a PC, but I don't think things are different for the
arm64
/armhf
combo.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.