Konzept für meine 2DX-Engine (DirectX)

[.chicken]

Hi, also ich wollte ja meine eigene 2D-Grafik-Engine mit DirectX schreiben.
Habe das Buch "DirectX9 in Delphi" nun fast zur Hälfte durch und wollte schonmal anfangen mir Gedanken über mein Konzept zu machen.

Also die Hauptklasse ist der T2DXController.
Er soll sowohl das IDirect3D9 als auch das IDirect3DDevice9 beinhalten und somit das Grundgerüst der Engine bilden. Er ermöglicht das simple Initialisieren von DirectX.
Außerdem wird der Klasse natürlich das Handle auf dem gezeichnet werden soll übergeben.

Dann brauche ich eine Unit die alle wichtigen Funktionen von DirectX abstrahiert. Z.B. das Erstellen von Texturen in eine kürzere Funktion kapselt und einfaches Transformieren ermöglicht.
Hinzu kommt eine Unit mit allen wichtigen Konstanten.

Eine Klasse T2DXModel.
Der Klasse wird beim Erstellen der T2DXController übergeben. Es ist sozusagen ein einfaches Rechteck. Von ihr werden weitere Klassen abgeleitet, die dann gegebenenfalls eine Textur enthalten und verschiedene Blendmodi umfassen. So würde sich denke ich mal auch simples Licht realisieren lassen. Außerdem kann man Reflektionen oder sowas einstellen.
Für animierte Models würde ich in einem bestimmten Zeitintervall die Texturkoordinaten transformieren.

Hieraus wird vielleicht noch ein T2DXBackground abgeleitet
Dieser sollte zB die Möglichkeit besitzen sich langsam gegen die Kamera zu bewegen, sodass es den Anschein hat, dass er sich langsamer mitbewegt weil er in weiterer Entfernung liegt.
Ich glaube sowas konnte man damals zB bei SuperMario sehen.

T2DXScene ist eine Liste von Objekten.
Man kann für die gesamte Szene Filter einstellen, wie zB Anisotropic oder Linear-Filter.
Außerdem wird das Rendern aller enthaltenen T2DXModels mit einem Befehl erlaubt.
Ich habe überlegt eine bestimmte Anzahl von Ebenen zu erstellen, die ich von hinten nach vorne überdecken. Der Background ist dabei natürlich die hinterste Ebene. Die Spielfigur könnte zB auf der Mitte liegen und so könnte man im Vordergrund noch Nebel oder Bäume darstellen.

T2DXCamera
Naja, die Kamera halt. Da alles nur im zweidimensionalen stattfindet, hat sie natürlich auch nur X und Y-Koordinaten. Vielleicht überlege ich aber auch noch ob die Kamera eine dritte Dimension erhält, mit der man dann leicht schwenken könnte oder sowas. Außerdem gibt es eine simple Zoom-Funktion. Drehen wird natürlich auhc möglich sein.

Vielleicht fehlt noch ein T2DXTimer
Naja den würde ich wahrscheinlich über die OnIdle Prozedur lösen und dann immer das Intervall zwischen dem Letzten TimerAufruf berechnen. So könnte ich dann alle Animationen gleich schnell ablaufen lassen.
Außerdem sollte er einen Geschwindigkeits-Multiplikator erhalten. Standard wäre dann zB 1, dh das Intervall wird mit 1 multipliziert bevor es an die Objekte weitergegeben wird. So könnte man dann mit einem Multiplikator von 0.5 eine einfache Zeitlupe erreichen.
Der Timer soll aber sehr unabhängig von der GrafikEngine sein.

T2DXText darf natürlich auch nicht fehlen
Natürlich mit verschiedenen Fonts und vielleicht einem Pseudo-3D-Effekt.



So habe ich mir mein bisheriges Konzept vorgestellt.
Es ist sicherlich relativ simpel gehalten, sollte aber trotzdem recht Leistungsstartk sein, oder nicht?
Außerdem, wäre es dadurch dass die Engine so schmal gehalten wird, mit Sicherheit sehr einfach zu lernen. Ich habe das Konzept sehr nah an das im Buch beschriebene angelehnt, was sicher damit zusammen hängt, dass ich es gerade lese.
Ich denke aber nicht dass das weiter schlimm ist.

Die Frage ist eher, ob ich weiter abstrahieren müsste. So bleibt die Engine sehr DirectX nah, außer dass die Funktionen umbenannt und vereinfacht und nützliche Klassen erstellt werden.
Ich habe mir kurz die Andorra2D Engine angesehn und dass sieht wesentlich entfernter von DX aus (sicher, weil es auch OpenGL umkapselt), allerdings sieht es mir auch wesentlich komplizierter aus.

Jetzt ist noch die Frage wie ich die GrafikEngine zB einfach mit anderen Teilen verbinden kann.
Wenn ich später für meine Spiele zB noch eine KollisionsEngine oder verschiedene Spielereigenschaften erstelle, dann wäre es ja blöd für einen Spieler 3Objekte zu erstellen:
-Spielergrafik
-Spielereigenschaften
-Spielerkollision
Ich denke ihr wisst wie ich das meine.


Was haltet ihr ansonsten von meinem bisherigen Konzept? Verbesserungen und Kritik sind sehr erwünscht. Vielleicht bin ich auch vollkommen falsch an den Aufbau ran gegangen?


Ich hoffe ich habe nichts vergessen. Meinungen bitte

Grüße, .ch!cken

[.chicken]

Hat denn keiner ne Meinung dazu?

[igel457]

Sieht soweit eigentlich ganz gut aus - schau doch einfach mal wie das funktioniert und wie weit du kommst.

[.chicken]

Ok, obwohl ich mich nicht wirklich an die von dir genannten Abstraktionsebenen gehalten habe? Das habe ich naemlich immernoch nicht ganz verstanden ^^

Grüße, .ch!cken

[mimi]

was ich an dein Konzept nicht verstehe ist warum braucht du für ein Player drei Objekte ?

Ich habe mir selbst eine kleine Engine in Lazarus für Canvas erstellt.
Dort hat jeder Sprite eine TBitmap variable die das Grafik Objekt enthält und es gibt einen eigene ImageList.
Die aus einer XML Datei ihrer Daten enthält, somit hat jede Grafik eine eindeutige IDE, einen namen und eine Gruppe.
ach ja und es werden nur die bereiche neu gezeichnet die sich auch wirklich verändert haben, also nicht ständig alles was natürlich viel einfacher ist. So umgehe ich die 100% CPU Auslastung und für mich reicht das.
und meine 2D Engine besteht auch 5 Klassen:
TPlutoImageItem, TPlutoImageList
TPluto2DEngine, TPluto2DSprite, TPluto2DSpriteManger
die haben alles Zugriff auf alle anderen Klassen. Ein Sprite gehört somit einer SpriteManger an der wieder rum zu einer 2D Engine angehört. Beim Zeichnen wird jetzt ein Event ausgelöst das alle Sprite in den bereich der neu gezeichnet wird, neu zeichnet, um Grafik Fehler zu vermeiden.

Meinst du sowas ?

[.chicken]

Ne, da haste mich falsch verstanden.
Das hat sich aber auch schon erledigt

Sonst noch Meinungen zu meiner Engine?

[.chicken]

Ok, also ich bin bisher ganz gut vorran gekommen und habe versucht das ganze soweit wie möglich flexibel zu halten. Dh. ich habe nur in meinem T2DXController die D3D9 und D3DX9 Units eingebunden und versuche darin sozusagen alle Funktionen umzusetzen. Letztendlich macht das die ganze Sache aber wesentlich komplizierter und das ganze wäre flexibler, wenn ich einfach überall Zugriff auf die DirectX-Funktionen habe.

Nun wollte ich fragen was eigentlich dagegen spricht? Also anfangs wurde mir ja empfohlen das ganze zu abstrahieren, sodass DirectX zB auch gegen OpenGL ausgetauscht werden kann. Ich habe aber sowieso nur vor mit DirectX zu programmieren, also ist es doch eigentlich vollkommen egal wie abstrakt ich das mache oder?

Würd gerne mal Meinungen dazu hören

[igel457]

Meiner Meinung nach zeugt es nicht gerade von gutem Programmierstil, wenn die Bibliotheks-/Plattformabhängigkeiten überall im Programm verstreut ist.

Natürlich macht es keinen Sinn, sich mit der Abstrahierung große Mühe zu geben, wenn es sich nur um ein einzelnes, kleineres Programm handelt und man sowieso nur auf eine Plattform setzten möchte.

Im Gegenzug wird der Quellcode viel Strukturierter, wenn man alle Abhängigkeiten nach außen hinreichend Kapselt. Dies spielt auch für die spätere Wartbarkeit eine große Rolle.
Nehmen wir mal an, Microsoft würde die Unterstützung von DirectX 9 aus seinen neuen Betriebssystemen herausnehmen: Dann würdest du mit deinem Programm plötzlich im Regen stehen: Dein komplettes Programm müsste jetzt umgeschrieben werden. Hast du hingegen die Zugriffe auf die Grafikschnittstelle hinreichend gekapselt, so musst du nur noch diesen kleinen Teil austauschen.

Zum Vergleich: Andorra 2D hat ca. 60.000 Codezeilen. Gerade mal ca. 2000 von diesen sind von einem Grafiksystem abhängig (jeweils 1000 für DirectX und OpenGL): Also nur ca. 4%! Anstatt 60.000 Zeilen neu zu entwickeln muss ich also nur einen Bruchteil davon umschreiben.

Wie gesagt: Die Kapselung lohnt sich IMHO nicht für ein einzelnes, kleines Programm, ist jedoch Sinnvoll, wenn du etwas Zukunftstaugliches herstellen möchtest.

Aber das ist nur meine Meinung, vielleicht kann auch jemand anderes etwas Sinnvolles zu diesem Thema beitragen.

[.chicken]

Ok, darf ich dich dann bitten mir einmal etwas genauer zu erklären wie ich das machen soll?
Also ich muss ja irgendwie zB "IDirect3DTexture9" benutzen um Texturen anzuzeigen.
Klar ich kann mir eine neue Klasse schreiben, die im Private Abschnitt eine Textur enthält, nur diese muss ja auch wiederum erstellt werden, wozu ich das Device brauche.
Das Problem ist, dass ich ja nicht wiess wie zB OpenGL arbeitet. Deswegen kann ich schlecht sagen inwiefern die Prozeduren und Funktionen aussehen müsste, damit ich sie mit gleichen Variablen auch mit OpenGL nutzen kann. Ich müsste mich da jetzt total reinlesen, was aber wenig Sinn macht ich möchte ja mit DX programmieren. Andererseits möchte ich dabei aber auch einen "guten Stil" einhalten und ich gebe dir vollkommen Recht, dass es schöner ist das zu trennen.

Als banales Beispiel: Sollte ich mir zB eine eigene T2DXMatrix schreiben, damit ich keine D3DXMatrizen verwenden muss?
Denn dazu müsste ich sie beim weitergeben an den Controller ja irgendwann wieder in D3DXMatrizen umwandeln und das würde doch Rechenzeit kosten?

Ach herrjeh, ich bitte um ein wenig Aufklärung

[igel457]

Ich fange mal mit einem einfachen Beispiel aus der Alltagswelt an.
Stelle dir vor, du hast zehn verschiedene CD-Spieler von zehn verschiedenen Herstellern: Du kannst alle CD-Spieler bedienen, weil sie alle die gleiche Schnittstelle nach außen haben: Es gibt einen Play, einen Pause und einen Open-Knopf. Du kannst eine CD einlegen.
Und auf der Rückseite des Gehäuses haben alle einen Chinch-Audio Anschluss den du an deinen Verstärker anschließen kannst.
Legst du eine CD ein und drückst auf Play, dann hörst du Musik.

Wie die Daten von der CD jetzt zum Audio-Ausgang gelangen ist jedoch von Hersteller zu Hersteller unterschiedlich. Der eine ist eine fest verdrahtete CMOS-Logikschaltung mit Widerstandsnetzwerk zur Digital-Analog-Wandlung, der andere verwendet einen kompletten 3GHz High-End PC mit PowerPC-Architektur und einem Linuxsystem, das beim Einschalten von der integrierten 300GB Festplatte geladen wird.
Doch uns braucht das als Anwender gar nicht zu interessieren, den Spieler betrachten wir also als eine Art "Blackbox": Wir verlassen uns einfach nur darauf, dass das Gerät das macht, das wir von ihm verlangen. Wenn ich auf "Play" drücke, will ich einfach nur Musik.

In deinem konkreten Fall könntest du als "CD-Spieler" (die Blackbox) die Kapselung der verschiedenen Grafikschnittstellen sehen. Die Tasten auf der Vorderseite des Geräts sind deine (frei definierte!) Schnittstelle zu deinem eigenen Programm: Imperialistisch sagst du von dort aus der Blackbox: "Initialisiere ein Fenster!" und sie macht es. Du sagst "Zeichne ein Dreieck an den und den Koordinaten!" und sie macht es.

Für dich bedeutet das: Was in der Blackbox passiert ist dir egal. Was zählt ist, dass die Implementierung deiner Schnittstellendefinition folgt.

Und nun kommt es:
DU bist derjenige der die Schnittstelle definiert. Du kannst diese Schnittstelle so machen, wie DU es für richtig hältst.
Dir kann es also egal sein, wie z.B. OpenGL funktioniert. Möchte man nun irgendwann mal OpenGL in deine Anwendung einbauen, so muss es halt innerhalb der Blackbox so implementiert werden, dass es das macht, was du über die Schnittstelle verlangst.

Ich hoffe, ich habe dir das Prinzip dahinter ein bisschen klarer gemacht. Natürlich ist es auch teilweise mit (geringfügigen) Geschwindigkeitseinbußen verbunden.Doch diese lassen sich durch sonst ordentliche und effiziente Programmierung dicke wieder rausholen. Und glaube mir - das Grundprinzip der Grafikschnittstellen ist durch den inneren Aufbau der Grafikkarte überall gleich, wodurch du dir darüber keine Gedanken machen musst: Auch jeder CD-Spieler basiert letztendlich auf dem gleichen Prinzip.