Es gibt eine lange Liste von verbreiteten Markup-Formaten. Xml und Json sind dabei den allermeisten Entwicklern ein Begriff. Auch Yaml ist ein Format, welches nicht zuletzt durch den Einsatz bei Kubernetes oder anderen bekannten Applikationen eine größere Verbreitung genießt. Yaml wirkt auf den ersten Blick wie ein “Json ohne Klammern”. Das habe ich selbst tatsächlich auch lange so angenommen. Beschäftigt man sich etwas tiefer im Detail mit Yaml, so wird man aber schnell eines Besseren belehrt. Yaml bietet mehrere Features und hat etwa bei der Ermittlung der Datentypen ein mehr oder weniger komplexes Regelwerk. Aber warum überhaupt Yaml, wenn man doch auch Json einsetzen könnte? Yaml-Dateien könnten leichter durch einen Menschen geschrieben und gelesen werden. Aus diesem Grund wird es gerne für Konfigurationsdateien verwendet – so wie etwa bei Kubernetes. Somit kann es auch für C# Entwickler sinnvoll sein, anstelle von Json oder Xml eben Yaml für Konfigurationsdateien zu verwenden. Aus diesem Grund möchte ich mich in diesem Artikel mit dem Parsen von Yaml Dateien mit C# beschäftigen.
Allgemeines
.Net 5 App Trimming am Beispiel MessageCommunicator
Das Tool MessageCommunicator (Siehe [1]) ist so konzipiert, dass es möglichst portabel sein soll. Idealerweise als schlichte Exe-Datei (bzw. ausführbare Datei auf Linux oder macOS). Mit dem Parameter PublishSingleFile ist das seit .Net Core 3.0 grundsätzlich möglich, einziges Problem ist lediglich die Größe der ausführbaren Datei. Man kann es sich aussuchen: Entweder man verteilt eine kleine Datei, setzt aber dann ein installiertes .Net am Zielsystem voraus, oder man hat eine größere Datei und bringt die Abhängigkeiten aus .Net direkt mit. Ich persönlich bevorzuge letzteres – es ist schlicht für alle Beteiligten einfacher, wenn eine Applikation möglichst wenig Voraussetzungen an das Zielsystem stellt. Mit den neuesten Funktionen rund um das App Trimming [2] kann an der Größe der zu verteilenden Dateien schrauben. In diesem Artikel möchte ich dazu meine Erfahrungen aus dem Projekt MessageCommunicator weitergeben.
Talks auf der ADC 2020 in München
Die Konferenz ADC 2020 fand trotz Corona statt und hat eine gute Plattform für Vorträge und Gespräche zu aktuellen Themen im .Net Umfeld geboten. Ich selbst war mit je einem Vortrag zum Thema WinUI und ASP.Net Core Blazor mit vor Ort in München. Die Coding-Beispiele beider Vorträge liegen entsprechend auf Github unter [1] und [2].
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.
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.
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.
Worklog RK Rocket #1: Basics
Aktuell arbeite ich relativ viel an der Integration von Direct2D in Seeing#. Diese API ist für mich der interessanteste Weg, 2D-Funktionen in eine auf Direct3D basierende 3D-Engine zu bringen. Man arbeitet mit aus anderen APIs bekannten einfachen Funktionen wie DrawRect, DrawLine oder DrawBitmap, ist aber vollständig hardwarebeschleunigt unterwegs und man kann direkt auf Texturen zeichnen, welche auf ein 3D-Objekt geklatscht werden. Oder schlich in den Vorder- bzw. Hintergrund der 3D-Ansicht. RK Rocket ist ein kleines Spiel, anhand dem ich die 2D-Funktionen in Seeing# integriere und direkt teste. Es ist ein einfaches kleines Game, inspiriert vom Rockout-Beispiel der Programmiersprache BlitzMax [1]. Es wird als UWP App erstellt und ist somit auf möglichst allen Windows 10 Geräten lauffähig.
RK2048 – Universal-App fast fertig
RK2048 ist mein erstes “Abenteuer” eine App mit weitgehend gleichem Coding auf mehreren Plattformen zu entwickeln und zu veröffentlichen. Genau genommen handelt es sich um (fast alle) aktuellen Windows-Plattformen von Windows Phone (8.1) über Windows RT bzw. Windows Store Apps bis Windows Desktop (Wpf). Es ist überraschend, wie gut das mittlerweile zwischen Phone und Tablet funktioniert, einzig WPF ist bei den Standard-Projekttemplates noch etwas außen vor. Im Windows Store ist die erste Version schon veröffentlicht, Windows Phone folgt (hoffentlich) relativ bald. Auch ein Setup für die Desktop-Version ist bereits verfügbar.
RK 2048 – Ein Spiel vollständig als Universal App entwickelt
Ein völlig verregneter Sonntag, nichts wirklich vor, was kommt dabei raus? Richtig, ein kleines Spiel. Letzten Sonntag habe ich die frisch auf Windows Phone portierte 3D-Engine verwendet, um einen kleinen 2048 Klon zu bauen. Der Screenshot zeigt das Ergebnis. Sieht an sich relativ gut aus und funktioniert auch überraschend gut. Ein paar Bugs gibt es sicherlich noch, ein paar Optimierungen für das Phone sind noch nötig, viel mehr als einen weiteren solchen verregneten Tag braucht es aber höchstwahrscheinlich nicht mehr. Das Besondere an dem Thema von der technischen Seite ist, dass es das neue Template für Universal Apps verwendet. Der gleiche Code läuft also für Windows 8.1 und für Windows Phone 8.1 – ganz ohne Compiler-Flags oder dergleichen.
Triangulation von WPF-Path Objekten
Zugegeben, der Titel dieses Beitrags hört sich etwas komisch an. Was Besseres ist mir aber leider nicht eingefallen. Im Grunde habe ich mir folgendes in den Kopf gesetzt: Ich möchte in meinem Programm diverse 3D-Objekte wie Pfeile, Böden (nicht nur rein rechteckige) o. Ä. relativ einfach dynamisch erzeugen können. Die Path-Objekte aus WPF bieten mir dafür schon die Grundlage, die ich brauche, nur leider lediglich in 2D. Daher habe ich ein kleines Programm geschrieben, welches aus einen Path per Triangulation-Algorithmus ein Modell aus Dreiecken errechnen kann. Daraus im Anschluss ein wirkliches 3D-Objekt zu machen, ist bekanntlich kein großes Problem mehr.