Seit einer ganzen Weile schiebe ich das schon vor mir her: Das Grundgerüst, welches ich die letzten Jahre für eigene Test-Entwicklungen, kleine Spiele etc. verwendet habe, möchte ich als OpenSource bereitstellen. Die Feature-Liste kann sich hierbei sehen lassen: Integration Direct3D/Direct2D, Integration in WPF/Win.Forms/WinRT, hohe Parallelisierung (Multithreading), Software-Rendering, Unterstützung mehrerer Grafikkarten und noch vieles mehr. Nun, da ich mein Studium im Januar dieses Jahres abgeschlossen habe, kann ich mich nun um das Thema OpenSource kümmern. ABER: Ganz so einfach wie „ich lads einfach mal hoch..“ ist es leider nicht.
Blog
Um was geht es beim Testen?
Neulich stand am .Net Usergroup-Treffen in Regensburg das automatisierte Testen auf der Agenda [1]. Grundsätzlich ein wichtiges Thema, nicht nur für mich, sondern auch für viele andere Softwareentwickler – alleine die hohe Teilnehmerzahl macht dies deutlich. An dieser Stelle direkt ein Dank an den Sprecher Kenny Pflug, er hat das Thema gut dargestellt – auch wenn es die eine oder andere Kritik an dem Beispielprogramm gab ;). Bei dem Vortrag konnte ich einige Dinge dazulernen, beispielsweise nennt sich das, was ich normalerweise als „Testdriven Development“ in der Arbeit vorantreibe, in Wirklichkeit „Behavior Driven Development“. Naja.. ich mache mir halt nicht viel aus Schlagworten 😉
Direct3D11, WPF und der Energiesparmodus
Direct3D 11 direkt in ein WPF D3DImage zu integrieren ist nicht ganz so einfach – das ist jedem bekannt, der das schon einmal probiert hat. Im Fall meiner 3D-Engine SeeingSharp gehe ich sogar noch etwas weiter: Das Rendering erfolgt komplett verteilt auf dem ThreadPool. Weiterhin werden so Kleinigkeiten wie Kantenglättung unterstützt, die die Integration in WPF auch noch etwas schwieriger machen. Nun habe ich es schon vor einer ganzen Weile geschafft, dass das auf allen getesteten Desktop-Rechnern gut funktioniert – aber irgendwie trifft man immer wieder auf neue Fälle. Neulich habe ich mir das neue Surface Pro 3 gekauft und siehe da… dort gibt es Probleme.
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.
MSTest, oder wie ich es verwende
UnitTests oder Ansätze der testgetriebenen Entwicklung werden aktuell häufig bei Usergroups oder Fachkonferenzen angesprochen. Erst diese Woche war ich auf einem Usergroup-Treffen in Nürnberg genau zu diesem Thema. Ich persönlich beschäftige mich damit schon etwas länger, habe testgetriebene Ansätze bereits mehrmals bei passenden Anwendungsfällen durchgeführt und war damit auch stets sehr zufrieden. Bei dem genannten Vortrag musste ich aber feststellen, dass sich das, was ich persönlich mit diesen Tests mache, mittlerweile schon teils deutlich von der Theorie unterscheidet. Hier in diesem Beitrag möchte ich entsprechend meine Sicht auf UnitTests und testgetriebene Ansätze im Allgemeinen beschreiben.Um ganz von vorne anzufangen: Ich verwende das in Visual Studio integrierte MSTest seit ca. 3-4 Jahren, vorher habe ich keinen einzigen automatisierten Test geschrieben. Ausgelöst wurde das ganze schlicht durch den Wunsch, gewisse Logiken nicht immer manuell neu testen zu müssen. Zudem habe ich an mir und auch bei Bekannten festgestellt, dass man sich gerne Testoberflächen bastelt, um damit neu entwickelte Logik-Bausteine zu testen. Diese Testoberflächen verschwinden aber gerne im Laufe der Entwicklung wieder oder werden aus Gründen der schlechten Usability einfach nicht mehr zum Nachtesten verwendet. UnitTests waren bzw. sind meiner Ansicht nach ein besserer Weg um genau das Gleiche zu erreichen. Vorteil: Die Testlogik bleibt im Projekt bestehen und kann jederzeit ausgeführt oder gar direkt in den Build-Prozess integriert werden.
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.
Portierung einer 3D-Engine auf Windows Phone #3
Vor einigen Wochen habe ich meinen 3D-Renderer auf Windows Phone 8.0 stabil zum Laufen bekommen und bin dabei auf die eine oder andere Hürde gestoßen. Da mittlerweile das Windows Phone 8.1 SDK verfügbar ist und auch SharpDX die entsprechenden Funktionen implementiert, konnte ich nun also einen neueren Weg ausprobieren – die Universal Apps. Vorteil: Dieser Weg verspricht, dass das Coding zwischen WinRT auf normalen Windows PCs und Windows Phone fast komplett identisch ist. Auch SharpDX verspricht, dass dieser Weg damit bereits gut funktioniert und nebenbei eine ganze Liste Nachteile der vorherigen Lösung ausbügelt.
Performance-Optimierung #1
Performance-Optimierung ist immer und überall ein Thema, welches viel Zeit und starke Nerven fordert. Zudem wird gerne an Stellen optimiert, welche für die Gesamtperformance letzten Endes nicht wirklich ausschlaggebend sind. Ich persönlich bin deswegen überwiegend der Meinung, während der Entwicklung selbst weniger auf Performance zu schauen und sich von Optimierungen nicht unnötig aufhalten zu lassen. Dort wo es hackt, kann im Nachhinein nachgebessert werden. Im Prinzip bin ich genauso bei der Entwicklung von SeeingSharp (Arbeitstitel für 3D-Engine) vorgegangen. Das Grundgerüst ist zunächst so aufgebaut, dass es aktuelle Anforderungen daran gut abdecken kann. Für künftige Aufgaben bin ich gerade dabei, an der Einen oder anderen Stelle zu schrauben, um so die nötige Leistung aus dem System zu bekommen. Die Schritte dazu und erste Ergebnisse erkläre ich kurz in diesem Beitrag.
Laden von Texturen auch auf Windows Phone
DirectX auf Windows Phone hat zwar zu einem großen Teil die gleiche API, wie auf dem Desktop, drum herum ist es aber z. T. stark eingeschränkt. Neben den Punkten aus den letzten Blog-Beiträgen (z. B. fehlendes Direct2D) hatte ich zusätzlich das Problem, dass ich bis jetzt fast durchweg png Dateien als Texturen verwendet habe. Grundsätzlich ja kein blöder Gedanke: Ein einfaches Dateiformat, welches man auch mit jedem Bildbearbeitungsprogramm bearbeiten und auch problemlos in eigenen Programmen verwenden kann. Auf dem Windows Phone funktioniert das aber nicht, da hierfür ausschließlich Texturen im dds Format zulässig sind. Daraus entstanden für mich im Wesentlichen zwei Probleme: Wie werden andere Dateiformate in dds konvertiert und wie können diese Dateien im Programm geladen werden?
Portierung einer 3D-Engine auf Windows Phone #2
Heute kam ich endlich einmal dazu, die Portierung auf Windows Phone wie im letzten Post beschrieben weiter zu machen. Kurzum: Das Ergebnis sieht mittlerweile sehr gut aus. Hürden gab es neben der zuletzt genannten zum Glück keine größeren mehr. Das einzig wirklich negative ist die Tatsache, dass die Synchronisierung zwischen Xaml-Rendering und Direct3D-Inhalt am Phone (natürlich) wieder anders ist, als auf allen anderen Windows Plattformen. Ich verwende den Weg über das DrawingSurface wie hier auf Msdn beschrieben.