Win 10 IoT und MonoGame auf dem Raspberry Pi 3 Testen


Ohne DirectX Hardware Beschleuniger ist die Performance eher auf dem Level, hmm.. Ich drücke das mal so aus: "Es geht". Dennoch ist interessant zu testen, was man eigentlich so auf dem Raspberry Pi erreichen kann. Für diese Tests verwende ich den Raspberry Pi 3 Model B+.

Testanwendung
Vom meinem letzten Blogpost Eintrag "3d Karte bewegen (MonoGame)" habe ich einen Branch angelegt, in dem ich die Inhalte für einen kleinen Benchmark aufbereite. Zum Beispiel wird die Eingabe mit dem GamePad oder Tastatur abgestellt. Hinzu kommen dann noch weitere 3D Objekte hinzu, die im Verlauf geändert werden. In der UI selbst wird dann die FPS und Durchschnittsergebnis der verschiedenen drei Durchläufen wiedergegeben.

Testumfeld, Quick and dirty
Der Test selbst ist nur sehr einfach gestrickt und sicherlich kann dort auch Optimiert werden. Aber das sollte diesmal nicht das Thema sein.

Durchläufe:
- 9 Objekte
- 100 Objekte
- 400 Objekte

Die Objekte sind auf 0.25 skaliert. Nur bei dem ersten können wirklich alle Kacheln gesehen werden. Bei den anderen Mengen, übertreten diese den Bildschirmrand.

Auf dem PC werden immer die 60 FPS erreicht. Der eingestellte Vsync beschränkt die FPS, was jedoch nicht weiter schlimm ist. Für den Raspberry Pi sollte die Beschränkung  kein Problem darstellen. Kommen wir zu den Testergebnissen

Ergebnis (Debug)

Die Anzahl der Bilder waren nicht sonderlich stabil und schwanke sogar relativ stark. Dennoch hat man erstmal so ein paar  Ergebnisse, die man versucht zu verbessern. Da wäre das Auslassen von 3d Objekten, die nicht zu sehen sind.

Was ist mit Core Application
Bisher noch nicht genutzt, aber ich dachte, es paßt gerade hier beim Testen. Also nahm ich den ganzen Code von der aktuellen Test Branch und erstellte ein Projekt mit Core Application. Klingt zunächst super.


Ergebnis (Debug)







Ergebnis (Release)







Nun, die Ergebnisse verhalten sich fast identisch wie der Normalen UWP Projekt. Teilweise hatte ich den Eindruck, daß die Ergebnisse schlechter waren. Das lag mit unter das die Ergebnisse bei mehreren Durchläufen sehr stark schwankten. Das änderte sich auch nicht, als ich den Test für eine Stunde laufen ließ.


Was ist mit 2D?
Vielleicht sollte man nicht zuviel auf 3D Inhalte setzen und lieber auf 2D setzen. Also habe ich von meinem vorigen Post und dessen Beispiel ebenfalls ein Branch erstellt und ähnliche Test Umgebung geschaffen in 2D und zunächst als UWP.


Ergebnis (Debug)







Zugegeben, das hatte ich nicht erwartet. Vielleicht liegt das an der zu rendernden Anzahl von Pixeln, die letztendlich in den Backbuffer landen. Offensichtlich  macht die Ausführung in 2D oder 3D keinen Unterschied. Die Schwankungen verhielten sich nicht anders.

Fazit
Das Testumfeld ist nicht sonderlich Realistisch, wenn man vom Optimieren absah. Die Frage ob man MonoGame verwenden kann auf dem Raspberry Pi, dann ist die Antwort ja. Wir stellen fest, die Antwort passt nicht zu den Ergebnissen. Warum ja? Mit Kompromissen, kann man durch aus MonoGame auf dem Raspberry Pi verwenden, wenn man Kompromisse eingeht. Mein Kompromiß ist Interesse.

Kompromisse die in erster Linie bestehen:
- Geringe FPS
- Geringe Auflösung um den FPS hoch zuhalten
- Ich will sehen, wie mein MonoGame Spiel auf dem Raspberry Pi (nicht) performt

Damit will ich das Thema Raspberry und MonoGame nicht schlecht schreiben. Denn nicht alle Spiele setzen auf hohe FPS. Das könnte ein 'Click and Point Adventure' sein.


Im Beispiel Video mit dem Raspberry Pi TFT, kann leider die Native Auflösung von 480x320 vom TFT nicht eingestellt werden.

Kommentare

Beliebte Posts aus diesem Blog

Arduino Control (Teil 5) - PWM Signal einlesen

Angular auf dem Raspberry Pi

RC Fahrtenregler für Lego Kettenfahrzeug