Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
1. Ich presse doch jetzt garnichts mehr in eine globale variable. Durch ein Prototype* Cube::cubePrototype = NULL; in der cube.cpp und dem deklarieren als private kann man sonst nirgends mehr auf die variable zugreifen, weder lesend, noch schreibend, nur innerhalb der klasse, was ja genau der gewünschte effekt ist.
2. RenderObject ist wie gesagt abstrakt, ich kann also kein RenderObject-objekt erzeugen. Ich verwende es eigentlich nur, um gemeinsam genutzte hilfsfunktionen an alle Kindklassen vererben zu können und Polymorphie nutzen zu können. Damit ich also eine RenderObject-std::list haben kann, und es mir egal sein kann, ob es jetzt Cubes oder Spheres sind. Deine Lösung würde so also nicht wirklich funktionieren.
[...] aber meiner meinung nach recht sauber.
Zu 1: In meinem programm eigentlich nicht, aber selbst wenn, kann man das ganze doch auch thread-sicher gestaltenKann/Darf es passieren dass mehrere Threads gleichzeitig ein Cube Objekt erzeugen?
Ist es möglich dass jemand versucht einen Würfel zu erzeugen bevor die statische Variable einen korrekten Wert bekommen kann?
Was wenn du mehr als einen OpenGL Context brauchst (z.B. weil du mit mehr als einem Fenster arbeiten willst)?
OK, so könnte man es machen, die neuen klassen wie CubeInstance hättest du erwähnen müssen Nur noch eine Frage: gibt es in deinem szenario jetzt nur 1 cube-objekt? Weil wie würdest du jetzt sicherstellen, dass alle Cube-Objekte den von ihren kreierten CubeInstances den selben pointer auf den Prototyp mitgeben? Meiner meinung nach sind wir dann wieder bei der ausgangssituation.Eben. Cube benutzt dann intern eine von RenderObject abgeleitete CubeInstance Klasse die das entsprechende Interface implementiert. Cube::CreateInstance() returned dann ein new CubeInstance(stuff). Polymorphie eben. Dass das so funktioniert kann ich dir versichern da ich das selber schon oft genug unter noch viel komplexeren Umständen (interne Daten sollen nicht unnötig redundant vorhanden sein aber alles muss gleichzeitig auf mehreren Grafikkarten verfügbar sein) erfolgreich so gemacht habe.
Ich stehe dem if da jetzt eher neutral gegenüber um die lebensdauer jetzt genau der lebenszeit aller cube-objekte anzupassen, hätte ich jetzt in den destructor noch ein if(Cube::counter == 0) Cube::deletePrototype(); gesetzt. sobald das letzte gelöscht wird, wird auch der prototyp gelöscht, und wenn wieder ein neues erzeugt wird, erzeugt dieses wiederum einen neuen prototypen. Theoretisch passen die lebensdauern tatsächlich nicht 100% zusammen, aber da C++ kein sprachliches konstrukt hat, welches genau diesen fall abdeckt, muss man es eben "praktisch" passend machen.Gut damit ist aber nur der Scope geregelt. Deine statische Variable hat immer noch nur den einzigen Zweck als Zugriffspunkt zu einem Objekt zu fungieren dessen Lebensdauer nicht statisch ist. Abgesehen davon musst du doch selber das Gefühl haben dass dieses if(!staticVar) im Konstruktor grottenhässlich ist!?
Zu 3: Hier erkenn ich nicht wirklich den zusammenhang
Nur noch eine Frage: gibt es in deinem szenario jetzt nur 1 cube-objekt? Weil wie würdest du jetzt sicherstellen, dass alle Cube-Objekte den von ihren kreierten CubeInstances den selben pointer auf den Prototyp mitgeben? Meiner meinung nach sind wir dann wieder bei der ausgangssituation.
Theoretisch passen die lebensdauern tatsächlich nicht 100% zusammen, aber da C++ kein sprachliches konstrukt hat, welches genau diesen fall abdeckt, muss man es eben "praktisch" passend machen.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (15.10.2010, 14:58)
OK, vielleicht solltest du das kurz irgendwie in Code erklären. Meine Klasse Prototype enthält wie du schon erkannt hast VBOs u.a. Angenommen ich will jetzt 5 Cubes rendern, die sich in position, rotation und skalierung unterscheiden. Dann erstelle ich 5 von "deinen" Cube-Objekten und mache die passenden transformationen darauf (d.h. auf die jeweilige modelview-matrix des cubes). Wenn ich das ganze jetzt rendern will, rufe ich Cube.createInstance(Prototype* p, ModelviewMatrix m) (oder so ähnlich) für alle 5 Cubes auf und dann wiederum CubeInstance.render() auf die 5 generierten CubeInstances. Meine Frage ist jetzt, wie stelle ich sicher, dass alle 5 Cube-Objekte den selben Prototype* p als parameter benutzen?Es gibt so viele Cube Objekte wie es braucht. Die Cube Objekte sind die Prototypen (auch wenn die Bezeichnung "Prototyp" hier etwas unglücklich gewählt ist). Wenn du nur einen willst hast du nur ein Cube Objekt.
Man kann Cube also als eine Art "Fabrik" verstehen.
Wenn das jetzt so stimmt, dann bräuchte ich aber doch eigentlich noch eine weitere Klasse, auf die ich dann die transformationen anwenden kann. Irgendwo muss ja die ModelviewMatrix gespeichert werden, oder?
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
// RenderObject.h class RenderObject { public: ... virtual void Draw(const matrix& ModelViewProjection) = 0; ... }; // Cube.h class Cube { private: whatever data; public: ... RenderObject* CreateInstance(const vector3& size); ... }; // Cube.cpp namespace { class CubeInstance : public RenderObject { private: whatever& data; matrix scaling; public: CubeInstance(whatever& data, const vector3& size) : data(data), scaling(size) { } void Draw(const matrix& ModelViewProjection) { ... } }; } RenderObject* Cube::CreateInstance(const vector3& size) { return new CubeInstance(data, size); } |
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (15.10.2010, 23:14)
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »n0_0ne« (16.10.2010, 10:22)
Werbeanzeige