Vulkan-Framework-Demoprogramm 1

Selbst als größter OpenGL-Fan muss man sich irgendwann einmal eingestehen, dass die OpenGL-API mittlerweile ein wenig in die Jahre gekommen ist. Als im Jahr 1992 die OpenGL-Spezifikation 1.0 veröffentlicht wurde, konnte man von massentauglichen Mehrkernprozessoren oder leistungsfähigen Grafikkarten allenfalls träumen. Da selbst so vermeintlich einfache Dinge wie eine Modifikation der Vertexfarbe mit einem nicht zu unterschätzenden Rechenaufwand verbunden waren, war es nur logisch, OpenGL in Form eines globalen Zustandsautomaten (Global State Machine) zu implementieren und die Werte sämtlicher Grafikpipeline-Parameter so lange beizubehalten, bis seitens des Hauptprogramms eine Änderung erfolgte. In der heutigen Zeit, in der die früher üblichen Single-Thread-Anwendungen längst zum alten Eisen gehören, wird diese einstmals vernünftige Design-Entscheidung jedoch mehr und mehr zu einem Problem. Sofern man den kompletten OpenGL-spezifischen Programm-Code innerhalb eines einzelnen Threads (dem sogenannten Rendering Thread) implementiert, ist man auf der sicheren Seite. Die parallele Verwendung mehrerer Rendering Threads im Rahmen einer OpenGL-Anwendung ist hingegen untersagt, da sich sämtliche Zustandsänderungen innerhalb der einzelnen Threads unweigerlich auch auf alle übrigen Threads auswirken würden. Für die Modellierung von Zustandsänderungen, die auf einen einzelnen Thread beschränkt bleiben sollen, ist ein globaler Zustandsautomat schlicht und ergreifend nicht geeignet. Ein weiteres Problem ergibt sich aus der Tatsache, dass man im Rahmen einer OpenGL-Anwendung sämtliche Arbeitsanweisungen auch einzeln an die Grafikkarte (GPU) übermitteln kann. Während sich besagte Anweisungen bei Verwendung eines einzelnen Rendering Threads noch problemlos interpretieren lassen, kann die Reihenfolge der einzelnen Anweisungen bei Verwendung von mehreren Threads vollkommen durcheinander geraten. Wie Sie sehen können, ist der in der breiten Öffentlichkeit hinlänglich thematisierte unverhältnismäßig hohe OpenGL-Treiber-Overhead nicht der einzige Grund, der für einen Wechsel hin zur neuen Vulkan-API spricht. Der größte Vorteil von Vulkan besteht vielmehr darin, dass wir im Unterschied zu OpenGL bei der Berechnung und Darstellung einer 3D-Szene nicht mehr auf einen einzigen Thread (normalerweise handelt es sich hierbei um den Hauptprogramm-Thread) beschränkt sind.

Alle hier veröffentlichten Demoprogramme erstellen wir mithilfe eines einfachen Vulkan-basierten Frameworks, welches wir mit jedem neuen Programmbeispiel Schritt für Schritt erweitern werden. Nun denn, verschaffen wir uns mal einen kurzen Überblick über die besonders hervorzuhebenden Features unseres ersten Demoprogramms:

E-Books zu unserer Tutorial-Serie rundum die OpenGL-Programmierung

Mit dem Ziel, Sie beim Durcharbeiten der einzelnen OpenGL Tutorials zu unterstützen, beleuchten die nachfolgend genannten E-Books gleichermaßen Grundlagen wie auch fortgeschrittene Techniken der modernen OpenGL-Programmierung sowie das für die Spieleentwicklung erforderliche mathematische Handwerkszeug.






  • Beim ersten Buch liegt der Fokus primär auf der OpenGL-Programierung.
  • Buch 2 behandelt gleichermaßen die OpenGL-Programmierung wie auch die für die Spieleentwicklung erforderlichen mathematischen Grundlagen.
  • Beim dritten Buch liegt der Fokus primär auf die für die Spieleentwicklung erforderlichen mathematischen Grundlagen:

Über die nachfolgenden Amazon-Partnerlinks gelangen Sie zu den Detailseiten der jeweiligen E-Books:


(Amazon Partnerlinks)

Zahlreiche Programmbeispiele zur weiteren Vertiefung der im E-Book behandelten Themen finden Sie auf unseren Internetseiten:

http://www.space-combat-and-strategy.spieleprogrammierung.net/














Blockbasierte Spielewelten – von Minecraft inspiriert (Update 2)

Zugegeben, seit unserem letzten Status-Update ist bereits wiederum einige Zeit ins Land gegangen.
Unser von Minecraft inspirierter Spieleprototyp wurde selbstverständlich kontinuierlich weiterentwickelt, und im „Entwickler-Magazin“ sind mittlerweile acht Artikel erschienen (Stand: April 2016), in denen sämtliche Entwicklungsschritte bis ins kleinste Detail erläutert werden.

Seit dem letzten Programm-Update können die blockbasierten Spielewelten nun hunderte von Kilometern im Durchmesser groß sein und werden in Echtzeit generiert, sobald sich der Spieler auf eine Erkundungstour begibt. Unterirdische Höhlensysteme und Rohstofflagerstätten warten auf ihre Entdeckung. Die Wasserdarstellung wurde komplett überarbeitet und es gibt endlich ein dynamisches Wettersystem mit Wind und Wolken (blockbasiert bzw. weichgezeichnet), mit Regen und Schnee sowie mit Blitzen und Nebel.