Zitat:
D3DDevice ist nat. vom Typ IDirect3DDevice9
Ja, das sagst du, dass das natürlich ist. In jeder C++-Anwendung ist IDirect3DDevice9 abstrakt und kann daher nicht instanziiert werden, folglich kann es innerhalb einer Anwendung nur Zeiger auf Objekte dieses Typs geben!
Ich programmiere D3D etc. nur mit C++, daher. Das sind halt so Delphi-Vereinfachungen, mit denen ich mich nicht hundertpro auskenne. Wenn man sowieso nur einen Zeiger auf so'n Objekt hat, ist es halt auch kein Ding, den zu übergeben ;c)
Zitat:
Eine Frage die sich mir zum Beispiel stellt ist die ob es wirklich sinnvoll ist die Position des 2D Objekts ausschliesslich über die Koordinaten der Dreiecke festzulegen, oder ob es nicht sinnvoller wäre das ganze über transformationen zu realisieren...
Richtig. Transformationen sind sinnvoller und einfacher, um gar nicht erst vom Geschwindigkeitsvorteil zu sprechen. Wenn du auf die Vertices nie zugreifen musst, kann auch kein Vertexzugriff das ganze verlangsamen ;c)
Zitat:
[...]weil ich Angst hatte dass die Methode sonst versucht ein ganz neues Objekt als eine Kopie des übergebenen anzulegen anstatt auf das vorhandene zuzugreifen.
Die Angst kenne ich - aber übergibt Delphi nicht ohnehin alle Klassentypen (also von Object abgeleitete) als Referenz? Das ist auch in C++ etwas anders...
Zitat:
ich habe mich bisher noch NULL (<- achtung: Wortspiel ) mit Zeigern beschäftigt
Man beachte insbesondere in diesem Zusammenhang meine Signatur
Zitat:
oder ist es technisch auch möglich zB. Hauptmenü und das Interface als einfache 2D Grafiken zu zeichnen
NEIN. Nicht in Direct3D ab Version 8. Oder sagen wir, es ist nicht vorgesehen. Wozu auch, denn die 3D-Hardware macht sowas (insbesondere skaliert, verdreht, transparent etc.) wesentlich schneller als jede 2D-Einheit. Und was den Aufwand angeht, nun, einmal einen Spriterenderer geschrieben, der funktioniert, dann ist die Benutzung desselben ja trivial.
Was ich dir empfehlen würde, ist, dass nicht jedes Objekt seinen eigenen Vertexbuffer haben sollte, sondern wie gesagt, ein Spriterenderer hat einen Vertexbuffer, in dem nur ein Rechteck drin steht, und die Positionierung, Texturierung, Skalierung und Drehung erreichst du mit Transformationen. Dasselbe gilt für die Texturen, die solltest du zentral verwalten, denn in einer Textur sind gewöhnlich mehrere Sprites (auch 128MB Texturspeicher sind GANZ SCHNELL voll (c; ).
Oh, und SetRenderState etc. nur zur Initialisierung aufzurufen ist nicht korrekt. Das merkst du ganz schnell, wenn du ein anderes Objekt rendern willst, das andere Renderstates benötigt... Auch hier kann ein Spriterenderer Abhilfe schaffen, indem du ihm zum Beispiel eine Begin- und End-Methode gibst, in der für alle Sprites diese Einstellungen vorgenommen werden können. So sparst du dir auch die SetStreamSource-Aufrufe, denn das muss für den Spriterenderer ja auch nur einmal pro Frame gemacht werden.
Wenn ich nicht irre, muss die Hardware die Transformationen SO ODER SO bei jedem Dreieck durchführen, so dass lediglich die CPU die Matrizen vorher berechnen muss - und die kann man dann zum Beispiel puffern, zum Beispiel für jedes Objekt. Auch macht es Sinn, zu testen, ob die Textur überhaupt gesetzt werden muss (weil sie evtl. noch gesetzt ist), oder alle Aufrufe für eine Textur zwischenzuspeichern etc.
Naja, und dann macht es vielleicht auch noch Sinn, sämtliche Renderstates etc. vor dem Spriterendern in einem Stateblock zu speichern, damit das wiederhergestellt werden kann - aber das ist nicht unbedingt notwendig ;c)