Start > Algorithmik > Labyrinthe und Irrgärten > labgen

labgen: Labyrinth-Generator

LabGen ist ein OpenGL-Programm zum Erstellen, Anzeigen und Durchwandern von Irrgärten, die als einfache Textdatei (Karte) erstellt werden können.

  1. Beschreibung
  2. Download
  3. Installation und Deinstallation
  4. Entwicklungsgeschichte

Beschreibung

Karte

LabGen übersetzt Karten in eine begehbare 3D-Darstellung. Dazu sucht es beim Aufruf im aktuellen Ordner nach der Karten­datei labgen.map mit folgendem Aufbau:

; labgen.map
######################
#     #              #
#     #              #
#  #  #  #  ### ###  #
#  #  #  #  #  #  #  #
#  #  #  #  #  #  #  #
#  #     #           #
?  #     #           #
?  ###########   #####
?  #     #           #
#  #     #  x        #
#  #  #  #  #  #  #  #
#  #  #  #  #######  #
#     #              #
#     #              #
######################

In diesem Textformat stellen Rautenzeichen Mauern und Leerzeichen den Boden dar. Optional kann ein x für den Startpunkt des Betrachters und ein ? für ein Ziel (z.B. Ausgang) angegeben werden, was zur Ausgabe der benötigten Zeit führt. Semikola leiten Zeilenkommentare ein.

Findet LabGen keine Kartendatei, generiert es eine eigene, zufallsbasierte Karte.

Ressourcen

LabGen sucht beim Aufruf im aktuellen Verzeichnis nach folgenden Ressourcen­dateien:

DateinameFunktion
bg.wavHintergrundmusik (Windows)
bg.mp3Hintergrundmusik (Linux)
bg.pngHimmel
wall.pngMauer

Somit läßt sich das Programm mit eigenen Texturen / Musik anpassen. Die obigen Dateien können als Beispiel und Startpunkt für eigene Anpassungen heruntergeladen werden.

Findet LabGen keine Ressourcen­dateien, verwendet es interne Ressourcen (Normalfall).

Steuerung

Im Programm schaltet F11 auf Vollbild um. Ein Nachtmodus ist verfügbar. Weitere Befehle finden sich in der Hilfe (F1).

Download

Das Programm kann als Archiv heruntergeladen werden:

Windows: labgen.zip [65 KB, 64 bit, MD5]
Linux: labgen.tgz [88 KB, 64 bit, MD5]

Nach dem Download ist eine Prüfung auf Virusfreiheit und Authentizität zu empfehlen.

Installation und Deinstallation

Installation oder Deinstallation des Programms sind nicht notwendig. Da sich das Programm nicht in System­dateien einträgt, ist ein portabler Betrieb möglich. Das Programm kann in einen Ordner eigener Wahl kopiert werden.

Getestet wurden Windows 10-11, Ubuntu 18, Mint 20-22 und Slax 9.11.

Windows

Das Programm benötigt keine systemfremden Bibliotheken.

Linux

Das Programm benötigt die Bibliotheken OpenGL, ALSA und FreeGlut, die in normalen Linux-Distributionen standardmäßig vorhanden sind (s. aber nachfolgende Ausführungen zu den einzelnen Systemen!).

Unter Linux kann statt einer einfachen Verknüpfung auf dem Desktop (Schreibtisch) eine sog. Desktop-Datei angelegt werden, die es erlaubt, ein Icon auf dem Desktop anzuzeigen und den aktuellen Ordner auf den Programm­ordner zu legen, damit Begleit­dateien (eigene Klänge, Texturen oder Karten) beim Programm­start gefunden werden.

Exemplarisches Vorgehen für einen Benutzer namens Tim:

  1. Die Programmdateien in einen Benutzerordner kopieren, z. B. nach /home/tim/bin
  2. Der Programmdatei labgen im Ordner ausführbare Rechte gewähren, z. B. 755
  3. Eine Desktop-Datei labgen.desktop im Ordner /home/tim/Schreibtisch mit folgendem Inhalt anlegen:
    [Desktop Entry]
Type=Application
Name=labgen
Path=/home/tim/bin
Exec=/home/tim/bin/labgen
Icon=/home/tim/bin/labgen.svg
    Statt labgen.svg ist auch eine andere Bilddatei möglich, z. B. labgen.xpm
  4. Der Desktop-Datei ausführbare Rechte geben, z. B. 755

Zum Austesten verschiedener Texturen, Klänge oder Karten ist ein Start im Terminal empfehlenswert, um Fehler­meldungen angezeigt zu bekommen.

Minimalsysteme

Unter Minimalsystemen wie z. B. Slax ist FreeGlut nachzu­installieren:
apt install freeglut3

Fehlendes FreeGlut

Unter Linux Mint 22 (Wilma) fehlt FreeGlut und ist nachzu­installieren:
apt install libglut3.12 oder
apt install freeglut3-dev oder
apt install libglut-dev

Fehlerhafte Default-Konfi­guration des PipeWire-ALSA-Plugins

Ebf. ab Wilma wurden Schrittklänge nicht mehr abgespielt. Grund ist eine fehlerhafte Default-Konfi­guration des PipeWire-ALSA-Plugins (behoben in labgen/1.3.1).

Fehlerhafte Paketierung von FreeGlut

Seit dem FreeGlut-Paket 3.4.0 findet labgen die Glut-Laufzeitbibliothek nicht mehr:

$ labgen
labgen: error while loading shared libraries: libglut.so.3: cannot open shared
object file: No such file or directory

Auch andere haben scheinbar dieses Problem:

Der dynamische Linker findet libglut.so.3 nicht mehr. Kein Wunder, eine solche Datei existiert im aktuellen Paket auch nicht mehr:

$ ldd labgen
linux-vdso.so.1 (0x00007fff5a190000)
libglut.so.3 => not found
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f9d7a73c000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f9d7a48a000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f9d7a457000)...

libglut.so.3 existierte noch unter dem Vorgängerpaket im üblichen Bibliothekspfad als Symlink auf libglut.so.3.9.0:

$ ls -la libglut*
lrwxrwxrwx 2 root root     16 Mai  9  2020 libglut.so.3 -> libglut.so.3.9.0
-rw-r--r-- 2 root root 311296 Mai  9  2020 libglut.so.3.9.0

Jetzt gibt es stattdessen eine libglut.so.3.12.0 und einen Symlink libglut.so.3.12 darauf:

$ ls -la libglut*
lrwxrwxrwx 1 root root     17 Apr 18  2024 libglut.so.3.12 -> libglut.so.3.12.0
-rw-r--r-- 1 root root 343872 Apr 18  2024 libglut.so.3.12.0

Da der dynamische Linker beim Erstellen von labgen aber gegen das interne SONAME-Feld libglut.so.3 der damals vorliegenden Bibliothek libglut.so.3.9.0 gelinkt hatte, braucht labgen auch unter dem neuen Paket immer noch libglut.so.3. Ein SymLink libglut.so.3, der auf libglut.so.3.12 zeigt, würde helfen, wurde aber durch das Paket nicht erstellt.

Ein zweites Problem ist der Wert libglut.so.3.12 des SONAME-Feldes der aktuellen Glut-Bibliothek, welches nicht dem Standard­namens­schema (nur Hauptversion im SONAME-Feld, s. Man Pages: Shared Libraries) entspricht:

$ objdump -p /usr/lib/x86_64-linux-gnu/lib[gG][lL]*.so | grep SONAME
SONAME  libGL.so.1
SONAME  libGLU.so.1
SONAME  libglut.so.3.12
SONAME  libGLX.so.0

Es gibt dieses Schema aus einem guten Grund: Solange nämlich die FreeGlut-Entwickler im Quellkode die bestehenden Funktions­aufrufe nicht ändern, sondern nur interne Änderungen oder Optimierungen vornehmen, sollte nur die Unter­versions­nummer angehoben werden und somit laufen alle Programme, die freeglut brauchen, unverändert weiter; sie müssen nicht neu kompiliert werden, s. a. Redhat - Creating C or C++ Applications:

A library foo version X.Y is ABI-compatible with other versions with the same value of X in the version number. Minor changes preserving compatibility increase the number Y. Major changes that break compatibility increase the number X.

Da sich nun aber auf einmal auch die Unterversionsnummer im SONAME-Feld findet, müßte ab sofort labgen (und jedes andere Programm) bei jedem Anheben der Unterversionsnummer von libglut rekompiliert werden.

Woher stammt der Bruch mit ABI-Kompatibilität und Namens­schema?

In der originalen, mit cmake verwalteten FreeGlut-Distribution findet sich folgender Code:

IF(FREEGLUT_BUILD_SHARED_LIBS)
  SET_TARGET_PROPERTIES(freeglut PROPERTIES VERSION ${SO_MAJOR}.${SO_MINOR}.${SO_REV}
  SOVERSION ${SO_MAJOR} OUTPUT_NAME ${LIBNAME})
ENDIF()
IF(FREEGLUT_BUILD_STATIC_LIBS)
  SET_TARGET_PROPERTIES(freeglut_static PROPERTIES OUTPUT_NAME ${LIBNAME})
ENDIF()

Wie man sieht, enthält er die Anweisung, ins interne SONAME-Feld nur die Hauptversion zu setzen, was korrekt ist. Die offizielle Quelle (upstream) ist also sauber.

Die nächste mögliche Fehlerquelle bilden die Paketierer der Linux-Distros. Da Software zuerst durch Debian paketiert und in Folge durch Ubuntu und Mint (ggf. mit kleinen Änderungen) übernommen wird, kann sich ein Fehler ab da (downstream) durchziehen. Schauen wir uns zunächst die Änderungen im Debian-Repo an:

File: 20_update_soversion.cmake
file content (17 lines) | stat: -rw-r--r-- 775 bytes
Description: Expand so-version to 3.11
Author: Anton Gladky <gladk@debian.org>
Last-Update: 2021-08-18

Index: freeglut-3.4.0/CMakeLists.txt
===================================================================
--- freeglut-3.4.0.orig/CMakeLists.txt
+++ freeglut-3.4.0/CMakeLists.txt
@@ -475,7 +475,7 @@ ELSE()
     ENDIF()

 IF(FREEGLUT_BUILD_SHARED_LIBS)
-  SET_TARGET_PROPERTIES(freeglut PROPERTIES VERSION ${SO_MAJOR}.${SO_MINOR}.${SO_REV}
   SOVERSION ${SO_MAJOR} OUTPUT_NAME ${LIBNAME})
+  SET_TARGET_PROPERTIES(freeglut PROPERTIES VERSION ${SO_MAJOR}.${SO_MINOR}.${SO_REV}
   SOVERSION ${SO_MAJOR}.${SO_MINOR} OUTPUT_NAME ${LIBNAME})
 ENDIF()
 IF(FREEGLUT_BUILD_STATIC_LIBS)
   SET_TARGET_PROPERTIES(freeglut_static PROPERTIES OUTPUT_NAME ${LIBNAME})

Und hier werden wir schon fündig: Durch den Debian-Paketbetreuer wurde cmake angewiesen, neben der Haupt- auch die Unterversionsnummer in die dynamische Glut-Bibliothek einzutragen. Dies führt zum Bruch der ABI-Kompatibilität und steht auch im Widerspruch zu Debians eigener Namenskonvention für dynamische Bibliotheken. Der Fehler wurde downstream auch nicht korrigiert; er zieht sich also durch bis Linux Mint!

Das Woher ist damit beantwortet. Zum Warum habe ich den Debian-Paketierer September 2024 per E-Mail angeschrieben. Eine Antwort kam bisher nicht.

Bis das gefixt wird, gibt es folgende mögliche Notbehelfe (dazu wurde labgen/1.3.1 so gepatcht, daß es wieder von einer libglut-Bibliothek mit dem SONAME-Feld libglut.so.3 abhängt, um auch auf etwas älteren Systemen lauffähig zu bleiben):

  1. Im Bibliotheksverzeichnis einen SymLink libglut.so.3 auf libglut.so.3.12 anlegen:
    $ cd /usr/lib/x86_64-linux-gnu
$ sudo ln -s libglut.so.3.12 libglut.so.3
    Nachteil: Bei jeder Anhebung der Unterversion oder bei Systemupgrades muß dieser Link angepaßt werden: 
    $ sudo ln -s libglut.so.3.13 libglut.so.3
$ sudo ln -s libglut.so.3.14 libglut.so.3
$ sudo ln -s libglut.so.3.15 libglut.so.3
...
  2. Soll die Bibliothek auch System-Upgrades überleben, empfiehlt sich statt­dessen die Installation der Bibliothek in das upgrade-sichere Verzeichnis /usr/local/lib/x86_64-linux-gnu/ (das Verzeichnis sollte in /etc/ld.so.conf.d/x86_64-linux-gnu.conf bereits gesetzt sein; wenn nicht, ist es einzutragen. Alternativ kann labgen mit LD_LIBRARY_PATH=/usr/local/lib labgen gestartet werden).
  3. Debians fehlerhaftes Paket umgehen und FreeGlut direkt von der sauberen Quelle (GitHub oder Sourceforge) herunterladen und kompilieren.

Entwicklungsgeschichte

Ziel: Weitgehende Unabhängigkeit von Bibliotheken, ohne Programmgröße aufzublähen.

Ver.Inhalt
0.9Prototyp, dankbar inspiriert durch Jeff Molofee auf nehe.gamedev.net.
1.0Gangbild und Kollisionserkennung.
Windows: Glut-Emulation, somit keine Abhängigkeit mehr.
1.1Spielerlogik, Edge Following.
RLE-Bitmaps und Wave-Audio-Dateien für Ressourcen.
1.2Zufallskarten und interne Ressourcen, somit LabGen einzeln lauffähig.
PNG statt Bitmaps.
1.3Monsterkrake PulseAudio durch mehr verfügbare ALSA-Bibliothek ersetzt.
Hintergrundmusik für Linux, Threads.
MP3 statt Wave-Audio.
Code-Überarbeitung, Programmgröße unter 100 KB gedrückt.
1.3.1Fix für PipeWire: In Mint 22 sind im standardmäßig installierten PipeWire-ALSA-Plugin nicht alle Audio-Formate des Safe ALSA Subset (U8, S16_LE, S16_BE, S32_LE, S32_BE, FLOAT_LE, FLOAT_BE, MU_LAW, A_LAW) bei Ausgabe auf das Standard-ALSA-Ausgabegerät (was auf PipeWire verweist) verfügbar, wie aplay zeigt:
aplay step.als
aplay: set_params:1371: Sample-Format nicht unterstützt
Die Ausgabe auf das Pulse-Plugin (-Dpulse) oder die direkte Ausgabe über PulseAudio (paplay) oder PipeWire (gw_play) funktionierten hingegen tadellos.
Lösung: LabGen testet nun mehrere Ausgabegeräte.
Fix für falsches SONAME-Feld von libglut.so: Patche DT_NEEDED in labgen von libglut.so.3.12 auf libglut.so.3.
© 2020, 2024 asdala.de: Kon­takt & Daten­obhut