spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Meiner Meinung nach ist ein TextureManager schon ein prädestinierter Fall für einen Singleton. Man könnte höchsten noch Einschränkungen machen, wenn man an Multithreading denkt. Aber wenn ich mich nicht täusche könnte man den TextureManager auch einigermaßen threadsafe machen womit auch nicht umbedingt ein Argument gegen den Singleton ist.
Manche werden natürlich sagen, dass man ja unter Umständen durchaus mehere TextureManager haben könnte. Aber der Sinn hinter dem TextureManager ist, finde ich, ja eben eine einheitliche zentrale Verwaltung für alle Texturen.

Wenn du es mit der Variante
machst, wird er jedesmal wenn du ein Textur der Liste hinzufügst eine neue Instanz von LoadedTexture Texture erstellen und dann mit dem = Operator kopieren - ist also tatsächlich nicht so gut. Am besten du verwendest einen Smartpointer. std::autor_ptr müsste in dem Fall reichen:
Dann zerstören sich die Texturenobjekte alle sobald der Destuktor von textureList aufgerufen wird. Ich muss allerdings zugeben, dass ich selber bisher nie so verfahren bin und einfach normale Pointer genommen hab und auch wieder selber jedes einzelne gelöscht hab . Aber nach meinen jetzigen Stand ist die genannte Lösung vernünftiger.

Zitat von ».:!Batzer!:.«

Also bevor ich hier wieder gelehrt bekomme, dass Singletons böse sind frag ich lieber
Ist es schlimm wenn ich meinen Texturen Manager als Singleton implementiere?
Funktionen wären dann: Load, Unload, GarbageCollector etc.

Der Fall mag vielleicht den Anschein erwecken das hier ein Singleton gerechtfertigt ist, aber:

• Du brauchst z.B. auf keinen Fall von überall Zugriff auf die Textureliste
• Warum um alles in der Welt sollte es nur einen Texturmanager geben dürfen? Du kannst ja z.B. (i.A.) davon ausgehen das die Schnittmenge der Texturobjekte pro Level (Levelgeometrie) und für Levelobjekte (Static Meshes, Animated Meshes) leer ist. Also wären hier wohl zwei Manager mit lokalem Zugriff sinnvoller. -- Warum sollte das Levelobjekt überhaupt Zugriff auf Modeltexturen haben dürfen?

Ein Singleton ist hier also eigentlich auch nicht gerechtfertig; Und garantiert nicht notwendig!

Zitat von ».:!Batzer!:.«

Und die andere Frage: Ich hae für eine Textur eine Struktur erstellt:

	C-/C++-Quelltext
1 2 3 4 5 6	struct LoadedTexture { unsigned int refCounter; IDirect3DTexture9* texture, std::string filename; };

kostet es leistung wenn ich die Instanzen der Struktur nicht per "new" erzeuge und dann in die Liste eintrage?

Das Kopieren von Instanzen ist hier teurer als das Kopieren von Zeigern. Dafür könnte (je nach Allocator) die Erzeugung der Instanz teurer sein... Ist aber alles erstmals zweitrangig, du solltest dir lieber Überlegen was für deine Zwecke mehr Sinn ergibt.

Zitat von »idontknow«

Kaum einer wird ein Spiel machen dass sonderlich viele Ressourcen verwednet die gleichzeitig viel Speicher brauchen

Doch, viele Spiele haben z.B. komplett andere Materialsets pro Level. Bei naiven Implementierungen schleppt man dann massiv Altlast mit sich rum. Das grenzt ja nahezu an ein Speicherleck!

Zitat von ».:!Batzer!:.«

Von überall kann man eben nicht darauf zugreifen, die Load, Unload funktionen sind private.
Im Fall des TexturenManagers ist z.B. die Sprite-klasse als friend definiert.

Wie du richtig erkannt hast macht ein globaler Zugriff kein Sinn (oder ist sogar gefährlich). Aber dieser Ansatz hört sich nach keiner guten Lösung an!

Zitat von ».:!Batzer!:.«

2 Manager werd ich nicht brauchen, da für 2D im meinem Fall nur textured quads benutzt werden, sprich nur texturen.

Du hast das falsch verstanden. Wenn du keine zwei Manager benötigst dann legst du eben nur eine Instanz an... Es geht nicht darum was du benötigst sondern warum du explizit nur eine Instanz erzwingen willst, was sind die Gründe dafür? Und "ich brauch nur eine Instanz" ist kein Grund!

Zitat von ».:!Batzer!:.«

Wenn es mehere Manager gäbe(kein Singleton) besteht doch immer die Gefahr, dass eine Textur 2, 3 oder mehr mals geladen wird.
Dann kann ich den auch einfach ganz weg lassen.

Klar kann sowas passieren. Wenn du die Instanzen vorsichtig verteilst minimiert sich das Risiko. Allerdings ist die Frage, ist es wirklich wichtig (ist deine Umgebung so Resourcenkritisch) das du dir ein oder zwei Duplikate auf keinen Fall leisten kannst? Oder ist das Softwaredesign wichtiger; und damit zusammenhängende Dinge wie z.B. Softwarewartbarkeit, Testbarkeit usw...

Zitat von ».:!Batzer!:.«

Speicherlecks sind theroretisch auch ausgeschlossen, da wenn z.B. ein Sprite-objekt zerstört wird die textur entladen bzw. der referenceCounter subtrahiert.

Das scheinst du auch falsch verstanden zu haben. Les dir meinen Post ggf nochmal durch.

Zum Diagram:

• RenderObject abstrahiert Shape, Font, Sprite, ... Ansich eine gute Idee (es sei denn die Abstraktion wird nicht benötigt).
  
• Video: Draw: Gut. Video scheint als Renderinterface gedacht zu sein. Wieso nutzt du hier nicht die Abstraktion die du für Renderobjekte hast (bzgl Sprite als Parameter)?
• Video::CreateTextureManager: Erzeugt einen Texturmanager, d.h. Video kann die Instanz führen. Es gibt also keine Notwendigkeit für ein Singleton-Texturmanager.
• Video: Scheint auf den ersten Blick das SRP zu verletzen.
• TextureManager::LoadTexture: Gut
• Sprite:: SetTexture: Ok, aber wieso wird SetTexture nicht in der Generalisierung angeboten? Es scheint für Font und Sprite zu passen, für Shape nicht unbedingt (Designfehler?). Möglicherweisse fehlt auch eine Abstraktionsebene...

Ansonsten stellt das Diagramm nicht viel mehr Informationen bereit.