In Vorbereitung für ein neues Spiel habe ich heute die Kern-Logik von Seeing# an ein paar Stellen erweitert. Wichtigster Punkt dieser Tage ist der Messenger, welcher in den Klassen von Seeing# als SeeingSharpMessenger bezeichnet wird. Ursprünglich habe ich mich bei dem Konzept etwas vom EventAggregator des Prism-Frameworks inspirieren lassen [1]. Grundsätzlich geht es darum, eine gemeinsame Klasse zu haben, an der sich Ereignis-Empfänger registrieren können, um so Ereignisse von beliebigen Quellen der Anwendung zu empfangen, ohne diese Quellen selbst zu kennen. Bei Seeing# habe ich dieses im Grunde sehr einfache Prinzip hauptsächlich dahingehend erweitert, damit es besser mit verschiedenen Threads innerhalb des Programms umgehen kann.
Roland
Einstiegs-Tutorial für SeeingSharp
Seitdem ich den Code von SeeingSharp auf Github hochgeladen habe, bastle ich daran auch relativ viel rum. Ziel ist für mich aktuell, nicht nur einen Haufen Quellcode-Dateien auf Github zu haben, stattdessen sollen auch einige Einstiegshilfen und Wiki-Einträge verfügbar sein, dass sich andere Interessenten möglichst einfach einarbeiten können. Der erste Schritt zu diesem Ziel ist ein kleines Einstiegstutorial bestehend aus vier C#-Projekten, jeweils angelegt als Windows Store Apps. Warum jetzt genau Windows Store war für mich erst einmal Nebensache, wichtig und für alle Plattformen gleich ist der Aufbau der Szene, die Konfiguration der Kamera, die Definition von Animationen oder die Suche nach Objekten unterhalb des Maus-Cursors.
3D-Engine SeeingSharp goes OpenSource #2
Endlich erledigt, heute früh habe ich SeeingSharp zusammen mit dem Quellcode von RK 2048 auf GitHub unter [1] hochgeladen. Wie im letzten Post geschrieben, steht der Code unter GPLv3 und kann somit von jedem frei eingesehen, verwendet und modifiziert werden, sofern man sich an die Bedingungen der GPL hält. Für mich soll die Library in Zukunft als Basis für weitere Hobby-Entwicklungen, meine Vorträge/Artikel und für Posts auf dieser Homepage dienen.
3D-Engine SeeingSharp goes OpenSource
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.
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.