Supertuxkart auf dem Tablet

Seit einiger Zeit gibt es Supertuxkart mit einem Touch-Eingabegerät, also habe ich es mal ausprobiert … in groß 🙂

Supertuxkart auf dem Tablet

Wer meine Artikelserie zum Pinephone verfolgt hat, hat den Spieleartikel gesehen. Darin ist auch Supertuxkart und seine Problem auf der Fedoraversion des Pinephones beschrieben, z.b. die mangelnde OpenGL3 Funktionalität der Mali400 GPU, was Supertuxkart in den Softwarerendermodus versetzt.

Dies Problem haben wir auf meinem Surface Pro Tablet natürlich nicht:

Ja, es fuhr wirklich

Supertuxkart ist aufgrund der Bedienung auf Multi-Touchsupport angewiesen. Wenn der nicht da ist, dann kann man entweder lenken und Gas geben oder eine der Zusatzfunktionen nutzen, aber nicht beides gleichzeitig. In der Praxis bedeutet es die faktische Unspielbarkeit des beliebten Kartgames.

Zum Glück gibt es Jake Day

Wer sich an die ersten Artikel zum Surface Tablet im Blog erinnert, dem wird der Umstand wieder einfallen, daß es keinen Touchsupport fürs Tablet gab. Jake Day hatte das geändert, in dem er einen eigenen Kernel kompiliert hatte, in dem dieser Makel behoben wurde.

Mit dem alten Jake Day Kernel habe ich dann Supertuxkart so gespielt, wie das vorgesehen war. Leider auch hier nur mit mäßigem Erfolg, da zwar alle Zusatzfunktionen gleichzeitig zum Lenken auslösbar sind, aber die Lenkung selbst das Problem ist. Viel zu oft bleibt das Kart einfach stehen oder lenkt nicht mehr. Ein Lenkrad wie ein echtes Lenkrad zu drehen ist für Touch nicht die beste Lösung. Eine Wippensteuerung wie auf jedem Gamepad wärs gewesen.

Zusammen mit der Pressdruckerkennung des Touchdisplays wäre eine gelungene Steuerung sehr gut möglich gewesen. Vielleicht bekomme ich die Devs ja zu dieser Änderung 🙂

„Energie ist alles!“

Zu den „mechanischen“ Problemen der Steuerung kommt, daß man das Spiel nicht wirklich lange zocken könnte, da es viel zu viel Energie benötigt. Die 4 i7 CPU Kerne werden wegen 3D Berechnung für die 3K Auflösung schnell sehr warm, was die Lüfter dann kompensieren müssen, ein todsicheres Anzeichen für hohen Energieverbrauch 😉

Aber immerhin, für ein bisschen Unterhaltung reicht eine Akkuladung aus 😉 Da das Spiel netzwerkfähig ist, könnt Ihr fast überall mit anderen Zocken, ob Ihr gewinnen werdet, kann bezweifelt werden 😉

Ladet Euch mal das Bild aus dem Artikel runter, dann habt Ihr eine Idee zur Auflösung des Bildschirms. Natürlich kann man Supertuxkart sagen, es soll eine kleinere Auflösung benutzen, aber das das Display die M$ eigene 3:2 Auflösung benutzt, kommt es zu Verzerrungen, wenn man z.b. auf FullHD runterschaltet.

Gyroskopische Steuerung

Auf Android kann man SupertTuxKart tatsächlich über die Lagesteuerung spielen:

[dev] Gyroscope controls in SuperTuxKart, an opensource racing game
byu/_pelya inAndroidGaming

Das könnte das Problem tatsächlich lösen, da das Surface so groß ist, das ruckartige Steuerfehler wie im Video mit dem großen Tablet gar nicht möglich wären. Das ist definitiv wert einmal ausprobiert zu werden 🙂

Pinephone: Judgement Day!

Pinephone: wie man ohne Phosh ein Handyfeeling simuliert

Was haben Pinephone Apps und Android Apps nicht gemeinsam? Genau, jede Pinephone aka Linuxapp macht ihr eigenes Fenster in ihrer Lieblingsgröße auf. Das ändern wir heute.

Pinephone: wie man ohne Phosh ein Handyfeeling simuliert

Um das machen zu können, brauchen wir ein dauerhaft laufendes Programm. Idealerweise würde so etwas der Windowmanager übernehmen, der läuft eh, aber da es Gnome ist, naja, nicht so schnell umsetzbar. Also machen wir das mit einem Script: windowmaximixerwatch

#!/bin/bash

rm -f /tmp/liste
i="0"
while [ $i -lt 1 ];
do 
	windowmaximizer > /dev/null
	sleep 1
	RC=$(ps auxf| grep -c gnome-shell)
	if [ $RC -eq 0 ]; then 
		i=1
	fi
done

Diese Datei wird nach /home/pine/.local/bin/windowmaximizerwatch geschrieben

„Das macht ja gar nicht so viel“ Stimmt, aber das ist ja auch nur ein Teil davon. Wie man leicht erkennen kann, ist das eine Programmschleife, die nur dann abbricht, wenn kein Gnome-Shell-Prozess (mehr) vorhanden ist.

Das Programm „windowmaximizer“ ist auch nur wieder ein Shellscript, das die ganze Arbeit macht:

#!/bin/bash

#1 
ISONBOARDOPEN=$(wmctrl -l | grep -c Onboard)

#2 
RESOLUTION=$(xdpyinfo | grep dimens | awk '{print $2;}')
X=$( echo $RESOLUTION | awk -F "x" '{print $1;}')
Y=$( echo $RESOLUTION | awk -F "x" '{print $2;}')

#3
ORIENTATION="landscape"
if [ $Y -gt $X ]; then 
        ORIENTATION="portray";
fi

#4 
LASTORIENTATION=$(cat /tmp/display.orientation.last);
if [ "$LASTORIENTATION" != "$ORIENTATION" ]; then

        # REMOVE OLD IDs as all needs to get maxed newly, because we had a layout orientation switch
        rm -f /tmp/liste
fi

echo "$ORIENTATION" > /tmp/display.orientation.last;

#5 create new /tmp/liste if missing:

touch /tmp/liste

# place Onboard window at the correct position and define variables for wmctrl cmds:

if [ "$ORIENTATION" == "portray" ]; then

        wmctrl -l | grep Onboard | awk '{print "echo "$1";wmctrl -i -r "$1" -e 2,0,1170,720,270";}' | bash
        TOP=41
        WIDTH=720
        if [ $ISONBOARDOPEN -eq 0 ]; then 
                HEIGHT=1440
        else 
                HEIGHT=1130
        fi

else
        wmctrl -l | grep Onboard | awk '{print "echo "$1";wmctrl -i -r "$1" -e 2,0,450,1440,270";}' | bash
        TOP=41
        WIDTH=1440
        if [ $ISONBOARDOPEN -eq 0 ]; then 
                HEIGHT=720
        else 
                HEIGHT=410
        fi
fi 

#6 now ALL windows WITHOUT Onboard, that are still unprocessed ( not in our brain file ), get processed. This is needed as resizing causes a lot of pain to the eye, as it flickers, even if it's not needed.

LISTE=$(wmctrl -l | grep -v Onboard | awk '{print $1;}')

for id in $LISTE
do 
        echo "processing $id";
        RC=$(grep -c $id /tmp/liste)
        if [ $RC -eq 0 ]; then 
                echo "resizing $id"
                wmctrl -i -r "$id" -e 5,0,$TOP,$WIDTH,$HEIGHT
                wmctrl -i -r "$id" -b toggle,maximized_vert,maximized_horz
                wmctrl -i -r "$id" -e 5,0,$TOP,$WIDTH,$HEIGHT
#               wmctrl -i -r "$id" -b remove,fullscreen
                echo $id >> /tmp/liste
        fi
done

#7
# Now we check, if all ids in your brain file are still open windows. Thats needed, because same windows, get the same id, when they are closed and repopend.
# if they are closed we need to remove the id, because we need to reposition them again on next open.

LISTE=$(cat /tmp/liste)
for id in $LISTE
do

        RC=$(wmctrl -l |grep -c $id)
        if [ $RC -eq 0 ]; then
                # Entferne Windows die weg sind!

                echo "remove id $id";

                grep -v $id /tmp/liste > /tmp/liste2;
                rm -f /tmp/liste;
                mv /tmp/liste2 /tmp/liste;
        fi 
done

Diese Datei wird nach /home/pine/.local/bin/windowmaximizer geschrieben.

  1. wir stellen erstmal fest, ob das Onboard OSK läuft. Das ist wichtig für die Berechnung der Fenstergröße, auf die die Apps gezogen werden müssen.
  2. xdpyinfo teilt uns die Bildschirmauflösung und jede Menge anderen Kram mit.
  3. Anhand der ermittelten X/Y Koordinaten legen wir fest, ob wir im Landscapemode ( 1440×720 ) oder Portraymode ( 720×1440 ) arbeiten.
  4. Wenn sich die Orientierung innerhalb des letzten Aufrufes geändert hat, löschen wir die gesicherten FensterIDs, so daß alle Fenster auf die neuen Gegebenheiten umgeändert werden.
  5. nun repositionieren wir das Onboard OSK passend zur Orientierung an die richtige Stelle und berechnen gleich noch die Variablen für die Fensterhöhe und -breite.
  6. nun werden alle Fenster, deren FensterIDs wir noch nicht bearbeitet hatten, was in einer Datei gespeichert wird, auf Position gebracht. Das sind die, die in der letzten Sekunde noch nicht da waren.
  7. Natürlich muß man auch mal aufräumen, was in diesem Fall meint, daß alle FensterIDs aus der Speicherung entfernt werden, die nicht mehr präsent sind. Normalerweise würde man ja annehmen, daß FensterIDs fortlaufend sind, aber nicht bei uns, da werden die FensterIDs wiederverwendet. Tja.

Das funktioniert ganz gut, von Gnome selbst mal abgesehen. Alles was wir jetzt noch machen müssen, ist dem ganzen ein Desktopfile zu erstellen, damit es in der Appübersicht auftaucht:

[Desktop Entry]
Version=1.0
Name=WindowMaximizer
Name[de_DE]=WindowMaximizer
Exec=windowmaximizerwatch
#Terminal=false
Type=Application
StartupNotify=true
#Icon=cs-login
Icon=/usr/share/icons/Mint-X/apps/96/cs-login.svg
MimeType=x-content/unix-software
Categories=Network;
Keywords=web;internet;
X-Desktop-File-Install-Version=0.23

Diese Datei wird nach /usr/share/applications/windowmaximizer.desktop geschrieben.

Wenn alle Shellscripte mit chmod 755 versehen wurden, kann es losgehen. Ich rate dazu ein anderes Icon zu benutzen, da müßt Ihr allerdings selbst sehen, welches Ihr nehmen wollt.

Mit dem Gnome-Tweak-Tools ( Optimierungen ) kann man das Script als App im Startmenü platzieren und so sollte es beim nächsten Start des Desktops automatisch mitstarten. Wenn es das nicht tut, einfach von Hand selbst starten.

Ab nun werden alle-gnome Fenster maximiert und selbst bei Gnome-Fenstern klappt das gelegentlich ( die haben so eine Art Tagesform ). Wer das ganze verbessern will, kann noch eine APP Datenbank aufbauen, aus der z.b. festgelegt wird, ob eine Anwendung in Fullscreen gehen soll, oder nicht. Ist nur so ein Gedanke.. an einen weiteren Bugreport bei Gnome 😉 Natürlich habe ich das schon ausprobiert 😀

In 3 Tagen sehen wir uns wieder. Achtet auf die täglichen kleinen Pine Updates, die kommen alle außer der Reihe rein. Öfters Reinschauen oder gleich den RSS-Feed abonnieren.

 

Pinephone: Judgement Day!

Pinephone: Der Spiele Guide

Heute wollen wir mit dem Pinephone ein paar Spiele spielen. Wir schauen was geht, was nicht geht, und was gehen könnte.

Pinephone: Der Spiele Guide

Für diese Aktion empfehle ich den Landscapemode, also horizontale Ausrichtung des Display, wie auf dem Desktop. Dazu sollte man auch die Wayland Gnomesession auswählen, also nicht X11, da unter Wayland die Touchbedienung auch aktiv in die Programm übergeht, wenn es denn funktioniert.

Mir fangen mal mit einem negativ Beispiel an:

0AD

0AD kommt nicht über diesen Bildschirm hinaus.

Auch wenn 0AD das Vorzeigeprojekt ist, startet es zwar sauber und könnte auch 3D auf der Mali400 GPU vom Pine fahren, aber leider, schaltete es irgendwie die Touchkontrollen aus. D.b. es reagiert nicht auf Klicks und auch die Gnomegesten  zum Wechsel in die Aktivitätenübersicht sind abgeschaltet.

Unter Wayland konnte cih dem Spiel zwei Klicks entlocken, bevor Touch wieder zusammen bracht. So ganz funktional ist es daher leider nicht 🙁

Battle for Wesnoth

Ganz anders kommt allerdings Battle for Wesnoth daher. Das rundenbasierte Strategiespiel funktioniert Ad-Hoc mit allen Touchfunktionen. Zugegeben die Buttons sind leider nicht DPI skaliert, aber es funktioniert zufriedenstellend. Da allerdings das Spiel auf der GPU arbeitet, war auf dem Pine leider kein Screenshot in Vollbild machbar, daher muß ich Euch leider mit einem kleineren Exemplar befriedigen:

Battle for Wesnoth in der Aktivitäten-Übersicht

Das Spiel selbst ist Fullscreen, aber wie Ihr selbst seht, sind die Buttons etwas klein geraten. Noch etwas, so ganz reaktiv ist das Spiel nicht, was die Buttons betrifft, z.B. „Zug beenden“ unten rechts. Da muß man Doppelklickartig auf den Screen einschlagen 😉

Die Spielführung ist erschreckend gut auf Touch abgestimmt. Weniger erfreulich ist der Stromverbrauch des Pine. Eine halbe Stunde Spielspaß kosten Euch locker 20% Akkuladung 🙁

Supertuxkart

Als ich gerade SuperTuxKart testen wollte, brach gerade das Rawhideserversystem zusammen. Daher müssen wir jetzt leider schauen, ob die Fedora 33 Version aus dem Stable Build funktioniert 🙂 Praktischerweise sind alle Abhängigkeiten für das Paket bereits geladen und vorhanden.

SuperTuxkart startet etwas sehr langweilig und moniert gleich zu Beginn, daß wohl der OpenGL ES 3 Treiber veraltet wäre, es würde jetzt ohne GPU laufen wollen. Damit scheidet es leider als eins der TOP Spiele vom Pine aus 🙁

Natürlich wurde es trotz dessen angespielt 🙂

Ja, es kommt mit Lenkrad 😀

Komischerweise wollte es nicht im Fullscreenmodus starten… hmm.. Leider kann die Mali400-GPU kein OpenGL ES 3, damit wird die Spiel wohl nie funktionieren.

Auf einem Libre M5 für 799 $US läuft das alles flüssig, weil vernünftigen SOC verbaut mit vernünftiger moderner GPU.

Widelands

Tja, also Widelands (Die Siedler 2) failed mal total. Da funktioniert nicht mal das Startmenü zum Auswählen der Kampagnen.

Swell-Foop u.ä.

Hier ein Foto vom Desktop, sieht aber auf dem Pine genauso aus.

Die ganzen Gnome Games für den Desktop funktionieren auch auf dem Pine ohne „größere“ Probleme. Es wird nur komisch, wenn die Fenster größer werden. Spielt man z.B. Swell-Foop  mit der großen Karte, paßt die nicht auf den Screen, weswegen das Spiel dann unlösbar wird. Wie man als Programm, ein Fenster größer als der Bildschirm öffnet, ist mir ein Rätsel. Das müßte eigentlich failen.

Chess

Ich habe noch nie, nie!, so leicht gegen einen Computer im Schach gewonnen. Der wäre vermutlich auch auf den Schäferzug reingefallen, wenn mir der noch einfallen würde 😉

World of Warcraft

Also da muß ich Euch enttäuschen, die CPU hat a) die falsche Architektur  und b) die GPU ist dafür zu schwach, leider 😀

Fazit

Wenn also Spiele, dann eher ohne GPU. Das schränkt die Auswahl dann zwar ein, ist aber kein Beinbruch. Angry Birds wäre ja mal was gewesen. Das hätte man auch per Chromium als WebApp versuchen können. Da Chromium aber zu blöd ist ohne OpenGL3 nicht mal Texte auf einer Seite schreiben zu können, fällt das leider auch weg.

Wenn man es mal realistisch sieht, funktioniert das Pine zum Spielen tatsächlich, wenn man Abstriche akzeptieren kann. Natürlich fehlen die Knallerapps um das Telefon für Mobile Gamer auch nur ansatzweise interessant zu machen. Wenn mehr Apps die GPU unterstützen würden, sähe das vielleicht anders aus.

Mal sehen was im nächsten Bericht zum Pinephone drin ist. Telefonieren kann ich bislang damit unter Fedora nicht 😉

Pinephone: Judgement Day!