Es klingt schon nach einer sehr seltsamen Mischung, die aktuellste Version von ASP.Net Core mit OpenUI5 zu kombinieren. Doch genau mit dem Thema möchte ich mich momentan intensiver beschäftigen. Für diejenigen, die es nicht kennen: OpenUI5 ist die OpenSource-Variante des Frameworks SAPUI5. Es handelt sich dabei um ein JavaScript-Framework zur Erstellung von Business-Anwendungen primär für den Einsatz zusammen mit einem SAP-System. OpenUI5 enthält einen Großteil des Funktionsumfangs von SAPUI5, steht dagegen aber frei zur Verfügung.
Blog
Worklog SeeingSharp 2: Start
Für das Projekt Seeing# habe ich bereits sehr viele Stunden investiert. Begonnen mit dem 3D-Rendering ist das Framework über die Jahre sehr in die Breite gewachsen, etwa mit der Unterstützung für Video mit der Media Foundation oder einfachen Funktionen zur Wiedergabe von Musik und kurzen Sounds. Zudem habe ich öfters allgemeine Infrastruktur-Themen wie einen kleinen DI-Container, Übersetzungsfunktionen, etc. integriert. Der ursprüngliche Fokus auf 3D-Rendering ist dabei zum Teil stark verwässert. Aus diesem und anderen Gründen (siehe unten) habe ich mich dazu entschieden, einen größeren Breaking-Change zu machen und die Library grundsätzlich zu überarbeiten. Das Projekt befindet sich auf Github im Repository: https://github.com/RolandKoenig/SeeingSharp2. Bis Seeing# 2 aber die gleiche Funktionalität wie vorher Seeing# bietet, ziehen noch einige Wochen ins Land.
Automatisierte Tests mit Windows.Forms UI
Vor kurzem wurde ich auf einen kleinen aber blöden Fehler in Seeing# hingewiesen. Die Rendering-Hauptschleife ist abgebrochen, sobald man ein Windows.Forms Control von einem Parent ab und an einen anderen angehängt hat. Jetzt klingt das nach einem sehr seltenen Fall, aber auch diesen hätte ich ein paar Jahre zuvor explizit behandelt – allerdings im Rahmen eines Windows.Forms Programms. Im Laufe der Zeit ist dieser Fehler wieder in den Code gewandert, ohne dass er wirklich auffällt. Wer testet sowas auch immer wieder? Aus diesem Grund habe ich versucht, diesen Fall per Testautomatisierung zu behandeln, um so automatisch genau diesen Fall immer wieder abprüfen zu lassen.
SeeingSharp auf der XBox One!
Seit jetzt schon ein paar Monaten ist es möglich, Universal Apps auf der XBox One zu deployen. Auf diese Weise ist es möglich, mit C# Apps für die XBox One zu erstellen. Somit wird es langsam Zeit, dieses Feature mit Seeing# zu testen, denn generell läuft Seeing# innerhalb einer Universal App absolut stabil und bietet alle Funktionen wie am Desktop.
Gemeinsame Icon-Bibliothek in größeren Desktop-Apps
Je umfangreicher Desktop-Apps werden, desto größer wird auch ein Problem, welches zumeist zu Beginn der Entwicklung unterschätzt wird: Wo werden Icons abgelegt, welche von verschiedenen Programmteilen verwendet werden? Viele verschiedene Programmteile und Module (und wie sie auch immer genannt werden…), bei denen jeweils lokal Icons abgelegt werden, können nach einigen Jahren stetiger Entwicklung für Chaos sorgen. Bei meinen Projekten verstärkt sich das Problem zusätzlich aufgrund der Tatsache, dass sich ältere Windows.Forms- und neuere WPF-Komponenten mischen.
WPF Direct3D 11 Interop Performance
Momentan stecke ich wieder etwas mehr Zeit in die Entwicklung mit WPF. Zwar bin ich nach wie vor nicht der größte Fan davon vor allem, was die Performance und die Weiterentwicklung seitens Microsoft angeht, aber WPF ist für den Windows Desktop nun mal Stand der Dinge. Ein für mich sehr kritischer Punkt bei WPF ist die Interaktion mit Direct3D 11 Inhalten von Seeing#. Genau dieses Thema war für mich immer überraschenderweise der schwierigste Teil.
SeeingSharp in C#-Apps einbinden
In den letzten Wochen habe ich mich darauf konzentriert, Möglichkeiten zu schaffen, um Seeing# leichter in C# Apps einbinden zu können – völlig egal ob diese am Desktop oder als Windows Universal App laufen. Ziel ist, dass die Einbindung in allen Fällen möglichst einfach und möglichst ähnlich durchgeführt werden kann. Zu diesem Zweck habe ich die verschiedenen Steuerelemente für WPF und Universal Apps modifiziert, so gibt es jetzt in WPF einen eigenen Xaml-Namespace. Der größere Punkt ist aber eine Einführung eines Komponenten-Systems, mit dem man bereits im Xaml verschiedene Aspekte der 3D-Anzeige zusammenbauen kann. Beispielweise, welche Objekte dargestellt werden sollen und wie die Bedienung der Kamera funktionieren soll.
Worklog RK Rocket #3: Sound per XAudio2
Mit Audio-Wiedergabe per DirectX habe ich mit bis dato nicht wirklich beschäftigt – schlicht noch nie gebraucht. Bei einem Spiel wie RK Rocket sieht das aber anders aus, denn wenn der Spieler feuert, ein Ziel trifft oder getroffen wird, sollte auch ein entsprechender Ton aus den Lautsprechern kommen. Neben der technischen Umsetzung gibt es für mich an dieser Stelle das Problem, den richtigen Content (=Sound-Dateien) zu bekommen, die auch zur Lizenz des Quellcodes von RK Rocket passen (=LGPL). Am Ende war beides glücklicherweise deutlich einfacher, als gedacht.
SeeingSharp und .Net Native
Die letzte Zeit habe ich mich damit beschäftigt, den SampleContainer von Seeing# als App für den neuen Windows Store in Windows 10 zu veröffentlichen. Interessanterweise müssen alle Windows 10 Universal Apps mit .Net Native kompiliert sein, damit man diese hochladen kann [1]. Für kleinere Apps habe ich das vorher schon mal ausprobiert, es gab keine nennenswerten Probleme. Bei Seeing# allerdings musste ich einige Zeit rumspielen, bis es schließlich erfolgreich mit .Net Native kompiliert wurde und als Paket durch die Prüfungen des Windows Store ging. Hier in diesem Artikel habe ich ein paar Punkte zusammengestellt, die ich speziell dafür anpassen musste.
Worklog RK Rocket #2: Maus, Tastatur, Gamepad
Für RK Rocket habe ich damit begonnen, das Eingabe-System von Seeing# vernünftig auszuprogrammieren. Eingabesystem bedeutet in diesem Fall, dass Seeing# im Hintergrund automatisch die Status-Werte der angebundenen Eingabegeräte unabhängig von der aktuellen Oberflächen-Technologie (WPF, Win.Forms, WinRT) abfragt, in ein gemeinsames Format bring und dann an die aktuellen Spiele-Komponenten weiterleitet. Das klingt erst einmal einfach, ist aber nicht ganz zu unterschätzen. Probleme kommen etwa daher, weil auch jede Oberflächen-Technologie in Windows seine API ein bisschen anders bereitstellt. Weiterhin macht die Architektur von Seeing# selbst die Aufgabe nicht einfacher, da konsequent auf Multithreading, Multi-View und theoretisch auch mehrere Szenen gesetzt wird.