Organisation von Spielobjekten
-
Hoi,
ich habe in letzter Zeit etwas an kleinen 2D-Spielen herumgebastelt, erstmal benötige ich jetzt Animationen. Also habe ich einen Animator geschrieben, der Sprites animiert, läuft super.
Jetzt stehe ich vor der Designentscheidung wie ich animierte Objekte in meine Engine integriere. Bis jetzt existieren nur einfach Gameobjects (sichtbar/unsichtbar und verschiebbar) sowie Objekte mit physikalischen Eigenschaften (Kollision, Dynamik).
Also die Hierachie ist bis jetzt: GameObject -> PhysicalObject.
Zuerst wollte ich einen neuen Objekttyp AnimatedObject einbauen lassen, andererseits möchte ich vlt auch mal animierte Objekte ohne physikalische Eigenschaften und es wäre ziemlich unsauber leere/dummy Physikeigenschaften verpassen zu müssen.Ich denke die optimale Lösung wäre das DecoratorPattern, aber irgendetwas missfällt mir gerade daran. Habt ihr zufälligerweise ne bessere Idee?
Danke und Grüße,
Ethon
-
Zufällig habe ich da den Standard-Tipp: Component-Based Design.
-
Ich denk das Grundproblem ist hier, dass du graphische Repräsentation und logisches Verhalten in die gleiche Klassen packen willst, obwohl es eigentlich zwei unabhängige Dinge sind...
-
AnimatedObject wäre viel zu grob, weil es viele verschiedene Aspekte an einem "Objekt" geben könnte, die man animieren will.
Ich halte es da für sinnvoller, einen Animator zu haben, dem man sagen kann, was man animiert haben möchte (also beispielsweise, indem man eine parametrische Animation verlangt und einen Funktor mitliefert, der mit den Werten aufgerufen werden soll).
Und dann eventuell doch AnimatedObject als Basisklasse, in dem Handles auf die objektbezogenen Animationen abgelegt werden können, sodass Animationen implizit abgebrochen werden können, wenn die Objekte verschwinden.Aber ich liege eigentlich fast immer falsch bei solchen Designentscheidungen...
-
Danke schon mal.
dot schrieb:
Ich denk das Grundproblem ist hier, dass du graphische Repräsentation und logisches Verhalten in die gleiche Klassen packen willst, obwohl es eigentlich zwei unabhängige Dinge sind...
Ernsthafte Frage: Tu ich das?
Zufällig habe ich da den Standard-Tipp: Component-Based Design.
Schon beim Googeln gefunden aber danke.
Nach meinen ersten Eindrücken ein heftiger Komplexitäts- und Performanceoverhead für relativ wenig. Oder täusche ich mich da?AnimatedObject wäre viel zu grob, weil es viele verschiedene Aspekte an einem "Objekt" geben könnte, die man animieren will.
In einem 2D Spiel, bei dem hauptsächlich Spielfiguren etc beim Rennen/Klettern animiert werden?
Im Moment habe ich diese Animatorklasse, die eine Liste an Animationen und assozierten Bildern hat und dann halt eben immer der der Spriteklasse sagt, welches Bild sie anzeigen soll.Ich halte es da für sinnvoller, einen Animator zu haben, dem man sagen kann, was man animiert haben möchte (also beispielsweise, indem man eine parametrische Animation verlangt und einen Funktor mitliefert, der mit den Werten aufgerufen werden soll).
Und dann eventuell doch AnimatedObject als Basisklasse, in dem Handles auf die objektbezogenen Animationen abgelegt werden können, sodass Animationen implizit abgebrochen werden können, wenn die Objekte verschwinden.Aber ich liege eigentlich fast immer falsch bei solchen Designentscheidungen...
Ich lass es mir mal durch den Kopf gehen, weiß nur nicht ob ich es richtig verstehe was du meinst.
-
Sowas hier:
frameAnimation_.reset( new vis::BlendAnimation< vis::Linear, unsigned char >( std::bind( &Edit::SetFrameAlpha, this, std::placeholders::_1 ), 0.2f, 50, GetFrameAlpha(), 255 ) ); frameAnimation_->Start();frameAnimation_ speichert ein "Handle" auf die Animation.
Und die Animation sagt folgendes: Rufe Edit::SetFrameAlpha mit dem linear interpolierten char-Parameter von GetFrameAlpha() bis 255 auf, mit einem Intervall von 50ms über die Zeit von 0.2 Sekunden.So schreibt man halt den interessanten Code, der aus der Zeit den aktuellen Wert berechnet nur einmal und kann so ziemlich alles animieren. Für einen 3D-Renderloop bräuchte man natürlich das Inkrement usw. nicht und könnte eine einfache Liste dieser "Animatoren" vorhalten, die in der Animationsphase aufgerufen werden.
Naja, vielleicht ist das auch alles Grütze, aber hat bei mir ganz gut gefunktionockelt.
-
Ethon schrieb:
Nach meinen ersten Eindrücken ein heftiger Komplexitäts- und Performanceoverhead für relativ wenig. Oder täusche ich mich da?
Jain. Es wird immer besser, je komplexer dein Spiel wird. So wie ein vector z.B. auch schneller als list ist, obwohl du dauernd in der Mitte Elemente einfügst/entfernst, wenn du nur 6 kleine Elemente in dem Ding hast. Aber es skaliert eben nicht, genau so wie Vererbung hier nicht skaliert. Und das gilt sowohl für Performance (irgendwann wird dann nämlich zwangsweise virtual inheritance benötigt), als auch für die Programmkomplexität, weil Vererbung nun mal sehr stark bindet.
Jetzt ist natürlich die Frage: Lohnt sich das denn auch für so ein 2D-Spiel? Ich würde sagen, performancemäßig sicher, selbst wenn du etwas verlieren solltest weil du nur 3 Objekte auf dem Bildschirm hast, merkt man das nicht. Was die Komplexität angeht: Kommt darauf an wie Komplex dein Spiel werden soll. Je mehr lustige Sachen du einbaust, desdo mehr wirst du Vererbung hassen.
-
Ethon schrieb:
Ernsthafte Frage: Tu ich das?
Naja, also ich hab das
Ethon schrieb:
Also die Hierachie ist bis jetzt: GameObject -> PhysicalObject.
Zuerst wollte ich einen neuen Objekttyp AnimatedObject einbauen lassen, andererseits möchte ich vlt auch mal animierte Objekte ohne physikalische Eigenschaften und es wäre ziemlich unsauber leere/dummy Physikeigenschaften verpassen zu müssen.so interpretiert, dass du eben entweder dein PhysicalObject von GameObject abgeleitet hast oder umgekehrt, wobei PhysicalObject logisches Verhalten kapselt und GameObject bzw. AnimatedObject graphische Repräsentation. Durch die Ableitungsbeziehung sagst du nun aber, dass entweder ein PhysicalObject auch ein GameObject ist, oder umgekehrt...
-
dot schrieb:
Ethon schrieb:
Ernsthafte Frage: Tu ich das?
Naja, also ich hab das
Ethon schrieb:
Also die Hierachie ist bis jetzt: GameObject -> PhysicalObject.
Zuerst wollte ich einen neuen Objekttyp AnimatedObject einbauen lassen, andererseits möchte ich vlt auch mal animierte Objekte ohne physikalische Eigenschaften und es wäre ziemlich unsauber leere/dummy Physikeigenschaften verpassen zu müssen.so interpretiert, dass du eben entweder dein PhysicalObject von GameObject abgeleitet hast oder umgekehrt, wobei PhysicalObject logisches Verhalten kapselt und GameObject bzw. AnimatedObject graphische Repräsentation. Durch die Ableitungsbeziehung sagst du nun aber, dass entweder ein PhysicalObject auch ein GameObject ist, oder umgekehrt...
Also, ich hab bis jetzt nie die Physik als logischen Part genommen (weil bis jetzt der Physikteil nur Synchronisierung zwischen realem Objekt und dem Objekt in der Physikengine war). Wohl ein Denkfehler.
Am besten haue ich mal das kommentierte Interface raus, wie es im Moment aussieht (habe den Animator in die GameObject Klasse gesteckt, imho ist es da nicht falsch), bitte sagen wenn ich hier Mist entwerfe.
//////////////////////////////////////////////////////////// /// Represents a visible object which lives inside a world. //////////////////////////////////////////////////////////// class GameObject { private: TexturePtr m_texture; sf::Sprite m_sprite; std::shared_ptr<Animator> m_animator; bool m_runAnimation; public: //////////////////////////////////////////////////////////// /// Constructs a visible game object. /// /// \param texture : The default texture of the object, can be null. /// \param animator : The animator to animate the object, can be null. //////////////////////////////////////////////////////////// GameObject(TexturePtr texture, std::shared_ptr<Animator> animator); //////////////////////////////////////////////////////////// /// Destructor. /// //////////////////////////////////////////////////////////// virtual ~GameObject(); //////////////////////////////////////////////////////////// /// Places the game object at a world position. /// /// \param x : The x coordinate. /// \param y : The y coordinate. //////////////////////////////////////////////////////////// virtual void placeAt(float x, float y); //////////////////////////////////////////////////////////// /// Returns the game object's world position in pixels. /// /// \return : The world position. //////////////////////////////////////////////////////////// virtual sf::Vector2f getPosition() const; //////////////////////////////////////////////////////////// /// Rotates the game object. /// /// \param angle : The world rotation angle in degrees. //////////////////////////////////////////////////////////// virtual void rotate(float angle); //////////////////////////////////////////////////////////// /// Returns the game object's world rotation in degrees. /// /// \return : The world rotation. //////////////////////////////////////////////////////////// virtual float getRotation() const; //////////////////////////////////////////////////////////// /// Starts an animation which is known by the animator. /// /// \param name : The name of the animation. //////////////////////////////////////////////////////////// virtual void startAnimation(std::string const& name); //////////////////////////////////////////////////////////// /// Stops any animation and restores the original appearance. /// //////////////////////////////////////////////////////////// virtual void endAnimation(); //////////////////////////////////////////////////////////// /// Stops any animation but only resets the animation without /// restoring original appearance. /// //////////////////////////////////////////////////////////// virtual void stopAnimation(); //////////////////////////////////////////////////////////// /// Draws the game object to a RenderTarget. /// /// \param target : The RenderTarget to draw to. //////////////////////////////////////////////////////////// virtual void drawTo(sf::RenderTarget& target); //////////////////////////////////////////////////////////// /// Updates the state of the game object. /// //////////////////////////////////////////////////////////// virtual void update(); };PhysicalObject überschreibt nun in erster Linie Funktionen, die mit der Physikengine synchronisiert werden müssen, zb.
void Synthetic::PhysicalObject::placeAt(float x, float y) { // Move the game object. GameObject::placeAt(x, y); // Inform the body. b2Vec2 newPosition(x / ::getPixelPerMeter(), y / ::getPixelPerMeter()); m_body->SetTransform(newPosition, m_body->GetAngle()); }cooky451 schrieb:
Jain. Es wird immer besser, je komplexer dein Spiel wird. So wie ein vector z.B. auch schneller als list ist, obwohl du dauernd in der Mitte Elemente einfügst/entfernst, wenn du nur 6 kleine Elemente in dem Ding hast. Aber es skaliert eben nicht, genau so wie Vererbung hier nicht skaliert. Und das gilt sowohl für Performance (irgendwann wird dann nämlich zwangsweise virtual inheritance benötigt), als auch für die Programmkomplexität, weil Vererbung nun mal sehr stark bindet.
Jetzt ist natürlich die Frage: Lohnt sich das denn auch für so ein 2D-Spiel? Ich würde sagen, performancemäßig sicher, selbst wenn du etwas verlieren solltest weil du nur 3 Objekte auf dem Bildschirm hast, merkt man das nicht. Was die Komplexität angeht: Kommt darauf an wie Komplex dein Spiel werden soll. Je mehr lustige Sachen du einbaust, desdo mehr wirst du Vererbung hassen.Wird irgendwo ein konkreter Ansatz erklärt? Die Grundidee dass ein Entity erstmal komplett leer ist und echt jedes Feature (selbst Position etc) erstmal hineingestopft werden muss finde ich doof.
Decimad schrieb:
Sowas hier:
frameAnimation_.reset( new vis::BlendAnimation< vis::Linear, unsigned char >( std::bind( &Edit::SetFrameAlpha, this, std::placeholders::_1 ), 0.2f, 50, GetFrameAlpha(), 255 ) ); frameAnimation_->Start();frameAnimation_ speichert ein "Handle" auf die Animation.
Und die Animation sagt folgendes: Rufe Edit::SetFrameAlpha mit dem linear interpolierten char-Parameter von GetFrameAlpha() bis 255 auf, mit einem Intervall von 50ms über die Zeit von 0.2 Sekunden.So schreibt man halt den interessanten Code, der aus der Zeit den aktuellen Wert berechnet nur einmal und kann so ziemlich alles animieren. Für einen 3D-Renderloop bräuchte man natürlich das Inkrement usw. nicht und könnte eine einfache Liste dieser "Animatoren" vorhalten, die in der Animationsphase aufgerufen werden.
Naja, vielleicht ist das auch alles Grütze, aber hat bei mir ganz gut gefunktionockelt.
OKay, danke, jetzt versteh ichs.
Ich lass es mir mal durch den Kopf gehen, aber da ich das Spiel mit anderen basteln möchte die nicht ganz so fit in C++ sind versuche ich das Interface simpel zu halten, dh. ich muss abwägen ob der Komplexitätsoverhead die bessere Dynamik wert ist.
-
Vielleicht wirfst Du einmal einen Blick in den Source von Doom3. JC ist auch nicht so der Anhänger modernster C++-Techniken und das vielleicht auch mit gutem Grund. Das trifft bestimmt Deinen Geschmack.
-
Ethon schrieb:
Wird irgendwo ein konkreter Ansatz erklärt?
Ansätze? Ja. Konkretere Implementierungen? Selten. Und ich selbst kenne leider auch noch keine bei der ich denken würde "ja, das ist es". Besser als Vererbung sind aber wohl die meisten. Zudem gibt es sehr, sehr viele Interpretationen der Grundidee.
Ethon schrieb:
Die Grundidee dass ein Entity erstmal komplett leer ist und echt jedes Feature (selbst Position etc) erstmal hineingestopft werden muss finde ich doof.
Das ist aber eben gerade das Tolle an der Idee. Wir sehen doch sogar bei dir schon, dass du anfängst ein Gottobjekt zu bauen. Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert? Nein. Und das wird, wie gesagt, immer schlimmer je mehr Features deine Objekte bekommen. Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
-
cooky451 schrieb:
Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert? Nein. Und das wird, wie gesagt, immer schlimmer je mehr Features deine Objekte bekommen. Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
Zusätzlich: Wieso sollte PhysicalObject von GameObject erben und wieso genau std::shared_ptr?
-
Das einzig schlimme an der hier gerade auftretenden Situation ist, dass man sich an solcherlei Fragen so lange aufreiben kann (auf verschiedensten Erfahrungsleveln), dass man in dieser Zeit auch mit Gottesobjekten etwas schönes hinbekommt, Erfahrung sammelt, die Anforderungen besser kennen lernt, usw. Man kann das Gefühl einfach nicht kurz in einem Forenpost zusammenfassen, das entsteht, wenn man eine kleine Änderung hier oder dort im Verhalten haben will und auf einmal das ganze Kartenhaus zusammenbricht oder das Projekt anfängt, auf der Stelle zu treten. Und wenn es für alles eine Patentlösung gäbe, die man aus dem Lehrbuch mal fix nach zehn Regeln runterfummelt, dann wären entsprechende Produke in der Lizenz auch nicht so teuer.
-
Und eine zweite Anmerkung:
Wenn jemand mit dem Ziel, ein bestimmtes Spiel umzusetzen, anfängt eine flexible Engine zu programmieren, so wird das Spiel in 99% der Fälle nie auch nur ansatzweise fertig. Das kann schlecht sein oder auch nicht, hauptsache es macht Spaß und man bereut die Zeit anschließend nicht.
-
Und noch eine dritte Bemerkung:
Wenn man irgendwann feststellt, dass man so ziemlich überall die Basisklassenfertigkeit überschreibt oder die Basisklassenfertigkeit mehrfach flexibilisiert, dann ist das ein gutes Indiz dafür, dass die Fertigkeit nicht in die Basisklasse gehörte.@dot: Ich lese im OP einen Pfeil von GameObject in Richtung PhysicalObject... Bedeutet das nach UML nicht, dass GameObject von PhysicalObject ableitet?
-
keine angst vor der editierfunktion
-
Decimad schrieb:
@dot: Ich lese im OP einen Pfeil von GameObject in Richtung PhysicalObject... Bedeutet das nach UML nicht, dass GameObject von PhysicalObject ableitet?
Ja, in UML, ich seh dort aber kein UML.
Aber gut, der Gedanke ist mir auch gekommen, für die Argumentation ist es aber irrelevant in welche Richtung die Ableitungsbeziehung genau läuft und die Variante schien mir rein intuitiv naheliegender.
-
dot schrieb:
cooky451 schrieb:
Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert? Nein. Und das wird, wie gesagt, immer schlimmer je mehr Features deine Objekte bekommen. Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
Zusätzlich: Wieso sollte PhysicalObject von GameObject erben und wieso genau std::shared_ptr?
Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
Ist doch ein klassischer Fall von shared Ownership. Eine Textur bzw ein Animator wird von mehreren Objekten geteilt. Ich verwalte zwar beide auch zentral, aber die Lebensdauer von Texturen/Animatoren an die Objekte zu binden erscheint mir als die richtige Lösung.
Und warum sollte PhysicalObject nicht von GameObject erben? Ein PhysicalObject ist immerhin auch ein GameObject, nur dass es parallel dazu noch in der "Physicsworld" lebt.
Decimad schrieb:
Das einzig schlimme an der hier gerade auftretenden Situation ist, dass man sich an solcherlei Fragen so lange aufreiben kann (auf verschiedensten Erfahrungsleveln), dass man in dieser Zeit auch mit Gottesobjekten etwas schönes hinbekommt, Erfahrung sammelt, die Anforderungen besser kennen lernt, usw. Man kann das Gefühl einfach nicht kurz in einem Forenpost zusammenfassen, das entsteht, wenn man eine kleine Änderung hier oder dort im Verhalten haben will und auf einmal das ganze Kartenhaus zusammenbricht oder das Projekt anfängt, auf der Stelle zu treten. Und wenn es für alles eine Patentlösung gäbe, die man aus dem Lehrbuch mal fix nach zehn Regeln runterfummelt, dann wären entsprechende Produke in der Lizenz auch nicht so teuer.
Ach, ich habe Zeit mir Gedanken zu machen weil der X-Server von Fedora17 nen Bug hat und der Patch noch nicht in den Repos ist ... und wegen dem Bug funktioniert SFML im Moment nicht. :p
Ansonsten gehe ich ja recht pragmatisch vor, nur das it den Objekten soll optimal umgesetzt sein.Vielleicht wirfst Du einmal einen Blick in den Source von Doom3. JC ist auch nicht so der Anhänger modernster C++-Techniken und das vielleicht auch mit gutem Grund. Das trifft bestimmt Deinen Geschmack.
Gute Idee, danke!
Das ist aber eben gerade das Tolle an der Idee. Wir sehen doch sogar bei dir schon, dass du anfängst ein Gottobjekt zu bauen. Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert?
Naja, meiner Meinung ist ein GameObject eigentlich immer etwas, das ich auch auf dem Bildschirm sehe. Von daher hat es immer Texture/Sprite. Den Animator dahin zu packen war eine Kurzschlussreaktion, aber ich fand/finde es nicht falsch die Teile, die mit der Darstellung des Objektes zu tun haben, auch zusammen zu haben.
-
Ethon schrieb:
dot schrieb:
cooky451 schrieb:
Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert? Nein. Und das wird, wie gesagt, immer schlimmer je mehr Features deine Objekte bekommen. Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
Zusätzlich: Wieso sollte PhysicalObject von GameObject erben und wieso genau std::shared_ptr?
Abgesehen davon: Für jedes Objekt die Textur im Speicher halten? Keine gute Idee würde ich sagen.
Ist doch ein klassischer Fall von shared Ownership. Eine Textur bzw ein Animator wird von mehreren Objekten geteilt. Ich verwalte zwar beide auch zentral, aber die Lebensdauer von Texturen/Animatoren an die Objekte zu binden erscheint mir als die richtige Lösung.
Mehrere Objekte verwenden die selbe Textur bzw. den selben Animator. Das wäre unter Umständen vielleicht eine notwendige, aber ganz sicher keine hinreichende Bedingung für shared Ownership.
Überleg dir nochmal, ob dir das tatsächlich als die richtige Lösung, oder nicht doch nur als die einfache Lösung erscheint...
Hint: Wieso genau sollte bei der Zerstörung eines GameObject auch dessen Textur oder Animator zerstört werden?
Ethon schrieb:
Und warum sollte PhysicalObject nicht von GameObject erben? Ein PhysicalObject ist immerhin auch ein GameObject, nur dass es parallel dazu noch in der "Physicsworld" lebt.
Ist jedes PhysicalObject wirklich auch ein GameObject? Wo genau kommt jetzt das AnimatedObject ins Spiel? Dein initiales Problem zeigt doch, dass deine Konzepte GameObject, PhysicalObject und AnimatedObject irgendwie im Widerspruch zueinander stehen...
Ethon schrieb:
Das ist aber eben gerade das Tolle an der Idee. Wir sehen doch sogar bei dir schon, dass du anfängst ein Gottobjekt zu bauen. Ist jedes Objekt sichtbar? Nein. Hat jedes sichtbare Objekt eine Textur? Nein. Ein Sprite? Nein. Ist jedes Objekt mit Textur animiert?
Naja, meiner Meinung ist ein GameObject eigentlich immer etwas, das ich auch auf dem Bildschirm sehe. Von daher hat es immer Texture/Sprite. Den Animator dahin zu packen war eine Kurzschlussreaktion, aber ich fand/finde es nicht falsch die Teile, die mit der Darstellung des Objektes zu tun haben, auch zusammen zu haben.
eigentlich immer oder immer?
Stell dir einfach folgende Frage: Ist es für das Konzept eines GameObject wesentlich, dass jedes GameObject immer aus einer Texture bzw. eine Sprite besteht? Wenn die Antwort nich klipp und klar "Ja" lautet, dann sind Texture bzw. Sprite dort fehl am Platz.
-
@Ethon Und schon bist du bei PhysicalObject und AnimatedObject, aber der gute Tom kann leider beides und tadaa, virtual inheritance.
-
dot schrieb:
Mehrere Objekte verwenden die selbe Textur bzw. den selben Animator. Das wäre unter Umständen vielleicht eine notwendige, aber ganz sicher keine hinreichende Bedingung für shared Ownership.
Überleg dir nochmal, ob dir das tatsächlich als die richtige Lösung, oder nicht doch nur als die einfache Lösung erscheint...
Hint: Wieso genau sollte bei der Zerstörung eines GameObject auch dessen Textur oder Animator zerstört werden?
Naja, da ich mir offen halten will etwas Programmiertes auch mal auf einem Smartphone oä. mit wenig RAM laufen zu lassen, versuche ich im vorhinein die Möglichkeit offen zu halten oft ungenutzte Resourcen freizugeben.
So wie es jetzt ist kann ich meinen ganzen Texturencache bzw einzelne Texturenklassen mit einer einzigen Zeile Code freigeben ohne dass es irgendwo dangling ponter gibt. Würde ich normale Referenzen auf das geladene Texturobjekt haben, müsste ich beim Löschen jeder Textur aus dem Cache eine Garantie geben, dass sie nirgendwo sonst verwendet wird. Und da nicht nur die Spielobjekte die Texturen verwenden ist das unglaublich umständlich und gewinnen würde ich dabei auch nichts. (shared_ptr ist in diesem Kontext ja praktisch kostenlos)Deswegen gefällt mir die Logik: Ist eine Textur nicht mehr im Cache und wird sie von keinem Objekt mehr verwendet => Ab in die Tonne damit.
....
Ansonsten bin ich durch diesen Blogpost ( http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ ) mittlerweile auch der Meinung dass soetwas eine recht sinnvolle Sache ist. Vor allem gefällt mir die Idee dass so der Renderer sehr leicht austauschbar ist.
Jetzt heißt es brainstormen wie ich das einigermaßen performant und mit möglichst wenig dynamisch angefordertem Speicher hinbekomme.
