Ein Objektmanager ist API unabhängig. Nur Programmabhängig. Hm...ich weis nicht ob ein Objekt Manager wircklich so viel Nutzen bringt.
Wir nutzen jedenfalls keinen. Dafür aber ein Resourcen Manager. Ein Objekt besteht immer aus verschiedenen Resourcen (Mesh, Texturen, etc.). Der Resourcen Manager kümmert sich um das laden und entladen der Resourcen. Damit das au was bringt, liegt er erstens in einem anderen Thread und zweitens kann er au Resourcen währen der Laufzeit (InGame) entladen.
Das setzt natürlich einiges Voraus
Objekte in einer Liste zu verwalten und sie dann ständig suchen zu müssen, ist wircklich nicht die richtige Wahl. Es sollte dann eher einen Handle geben, der Angibt wo sich das Objekt befindet. Z.B. eine Adresse (wenn man std::list verwendet).
Der Vorteil eines Objektmanagers ist natürlich das man immer alle Objekte wieder freigibt. Spätestens wenn der Destruktor des Objektmanagers aufgerufen wird.
Wenn ein Objektmanager aber Objeke freigibt muss er sie auch laden können. Sonst ist es kein Manager mehr. Das setzt allerdings vorraus das der Objektmanager alle Objekte kennen muss. Man brauch als sowas wie eine Factory. Damit das Dynamisch bleibt, sollte es einen ObjMGr Client geben. Ein Objekt wird dann zusammen mit einer ID (Zahl, String) beim Manager Registriert und über die Factory kann dann der Manager das Objekt mit der ID erzeugen.
Void-Pointer sind zwar immer leicht zu handhaben, aber sie haben ein dickes fettes Problem. Man kann sie in jeden Pointer Konvertieren. Man läuft gefahr, das man ein void* in den Falschen Typ konvertiert und so das Programm einen nicht mehr Definierten zustand bekommt.
Man sollte also ein void* auf jedenfall vermeiden.
16.05.2024, 16:38
Zum Seitenanfang
