Vertex Buffer Objects (VBO)
Da sich die Frage aus dem letzten Artikel geklärt hat (ja, OpenGL ist SDL wahrlich aus vielerlei Gründen vorzuziehen) möchte ich nun mein neu erwonnenes Wissen teilen.
In diesem Artikel möchte ich mich mit Vertex Buffer Objects, kurz VBO, beschäftigen.
Viele werden den folgenden Sachverhalt kennen oder zumindest in der Theorie nachvollziehen können.
Angenommen wir haben eine TileMap. Den sichtbaren Ausschnitt der Karte (View) werden wir mit sehr hoher Wahrscheinlichkeit nicht in jedem Frame ändern, sondern er wird mehrere Frames überstehen. Je nach Kartengröße eventuell sogar die gesamte Spielzeit, da gar kein Scrolling nötig ist.
Versteht sich von selbst: ist die gesamte Karte kleiner oder gleich groß wie das Fenster -> kein Scrollen notwendig, da alles bereits zu sehen ist.
Allerdings zeichnet man üblicherweise in jedem Frame wieder und wieder die gesamte Karte. Und das braucht bei größeren Karten eine Menge Rechenlast.
Man kann zwar das ganze etwas abmildern, in dem man von vorn herein nicht sichtbare Teile der Karte nicht zeichnet, aber die sichtbaren Tiles/Teile der Karte müssen dennoch immer und immer wieder über den Bus in den Grafikspeicher.
More »
D: Array-Extensions
Jeder, der mit D anfängt zu programmieren, freut sich über die wunderbaren Array-Funktionen die D von Haus aus mitbringt. Anders wie in C++ bestehen Arrays nämlich nicht mehr einfach aus einem einfachen Datenfeld, sondern beinhalten Informationen über die aktuelle Länge und auch ein paar nützliche Operationen wie den Slice-Operator.
Diese Feature sind ja auch schön und gut, wären aber noch nicht Grund genug, dass im Phobos-Framework keine einzige Klasse wie vector oder list zu finden sind. Nun ja, der wahre Grund hierfür ist, dass D noch ein weiteres Feature bietet: die sogenannten Array-Extensions. Es handelt sich dabei um Funktionen, die das Array in ihrer Funktionalität erweitert und man gleichzeitig den Eindruck gewinnt, dass die Funktion eine Memberfunktion des Arrays ist. Dabei ist folgende Regel zu beachten: Je allgemeiner man die Funktion implementiert ist, desto mehr Arrays haben die Möglichkeit, die Funktion zu nutzen. Es empfiehlt sich also generisch, sprich mit Templates zu programmieren.
More »
D: gleichnamige Methode als Template führt zu Konflikt
Vor ein paar Tagen fiel mir ein Bug oder zumindest ein merkwürdiges Verhalten in D auf.
Jeder kennt das nette Feature, dass zwei Methoden den gleichen Namen tragen dürfen, sofern sie sich in ihren Parametern (und/oder return Typ) unterscheiden.
Außerdem ist es möglich, das eine der gleich benannten Methoden ein Template ist.
Bspw. möchte man eine Koordinaten oder Rechteck Klasse haben, in der man explizit ein short für einen x oder y Punkt zurückerwartet, aber möchte dem Benutzer das manuelle umcasten von bspw. float in short Werte abnehmen.
Man definiert also eine Template Methode, welche einen impliziten Typ deklariert den man später in der Methode zu short castet (idealerweise nur, wenn es nicht schon ein short ist 
).
More »
How to: Templates und Operator Overloading
In diesem Artikel möchte ich die Nützlichkeit von Templates (vor allen was Makro Anhänger in C++ angeht) und dem überschreiben von (Arithmetischen) Operatoren in C++ und D zeigen.
Ich werde ein bei mir aktuelles Bsp. aufgreifen und dann einen Lösungsweg Stück für Stück in D entwickeln, aber auch den C++ Äquivalent dazu.
Vielleicht kennt jemand das Problem schon:
Angenommen, man hat eine derartige Template Struktur
alias Vector2!(float) Vector2f;
alias Vector2!(short) Vector2s;
struct Vector2(T) {
T x, y;
this(in T x, in T y) {
this.x = x;
this.y = y;
}}
Und des Weiteren hat man ein Element wie Vector2f v1 = Vector2f(1.5, 2.3); und muss es, aus irgendeinem Grund, in einen Vector2s umwandeln/casten.
Wie stellt man das am besten an?
More »
Sprites, Nachtrag
Vor einiger Zeit verfasste ich ja bereits ein Tutorial zu Sprites und der zugehörigen Klasse.
Mittlerweile weiß ich, dass das ganze wesentlich einfacher bzw. besser ginge, unter anderem mittels des Keywords @property.
More »