spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »TigerClaw25«

Das hier geht leider nicht: Spieler1.ptr , obwohl es auf den ersten Blick den Anschein macht.

Das leifert ja auch einen Pointer. Das sagte ich doch bereits.

Zitat von »TigerClaw25«

Wenn ich dem Zeiger aber aus versehen im Konstruktor NULL zuweise, komme ich garnicht dazu mein Bild zu laden, weil die Bedingung immer zutrifft.

Du vergleichst da auch Äpfel mit Birnen. Sprich eine lokale Variable mit einer Eigenschaft der Klasse. Das kann so nichts sinnvolles tun. Da sollte sicher 'pTemp' geprüft werden.

Zitat von »TigerClaw25«

Im Buch steht, dass "pRenderer" nicht in CSprite freigegeben werden darf. Wenn ich bisher alles richtig verstanden habe, ist der Grund der, dass "g_pFramework->GetRenderer()" im Prinzip einen Zeiger auf das erzeugte Objekt zurückgibt. "m_pRenderer" bekommt also einfach eine Adresse eines anderen Zeigers von Framework, der auf die Speicheradresse des Objekts zeigt. Das heißt, wenn man "m_pRenderer" im Destruktor von CSprite freigibt, den zurückgegebenen Zeiger von "g_pFramework->GetRenderer()" aber woanders weiter verwendet, ist dieser undefiniert. VErstehe ich das richtig?

An sich ja. Du versuchst das ganze aber viel zu technisch zu betrachten. Das Framework erstellt einen Renderer. Eine Sprite muss den Renderer kennen um sich selbst rendern zu können. Das Framework erstellt jetzt den Renderer und speichert sich diesen intern irgendwie ab. Es bietet mit GetRenderer die Möglichkeit von extern auf diesen Renderer zuzugreifen. Dafür liefert die Funktion die Adresse zu eben diesem zurück. Würde die Funktion einfach ein Renderer Objekt zurück liefern so würde dies an dieser Stelle kopiert und du möchtest nicht viele Renderer haben sondern einfach einen welcher von deinen Sprites verwendet wird. Deshalb merkt sich die Sprite einfach die Adresse zu der jeweiligen Instanz. Würde eine Sprite im eigenen Destruktor den Renderer zerstören so führt das schnell zu Problemen. Stell dir vor du hast ein Projektil welches zerstört wird. Dabei wird möglicherweise die Sprite des Projektils mit zerstört. Würde dadurch der Renderer zerstört so könnte nichts anderes vom Spiel gerendert werden. Das ist nichts was du willst. Um das ganze logisch auszudrücken, das Framework besitzt den Renderer und eine Sprite kennt den/einen Renderer.

Zitat von »TigerClaw25«

"if (m_pImage == NULL)" ist auch etwas unsauber. Wenn ich das richtig verstehe, zeigt der Zeiger "m_pImage", der in der Klasse deklariert wurde, auf irgend eine Adresse, nur nicht auf NULL; da nicht mit NULL initialisiert. Daher funktioniert das. Wenn ich dem Zeiger aber aus versehen im Konstruktor NULL zuweise, komme ich garnicht dazu mein Bild zu laden, weil die Bedingung immer zutrifft.

Der Code sieht nicht korrekt aus. In Zeile 11 möchtest du vermutlich m_pImage = ... und nicht pTemp = ... stehen haben.

Zitat von »TigerClaw25«

Aber dort ist es auch nur ein Zeiger auf "ein Objekt", der von der Funktion zurückgegeben wird Bishen zweideutig der Satz.

Zitat von »TigerClaw25«

Mich hatte es zum einen verwirrt, dass im Buch folgendes stand: "Wir holen uns ja kein Objekt sondern einen Zeiger darauf". Für mich klang das, als würde im Framework das Objekt selbst verwendet werden. Aber dort ist es auch nur ein Zeiger auf "ein Objekt", der von der Funktion zurückgegeben wird Bishen zweideutig der Satz.

Das klingt etwas verwirrend. Wichtig ist dass man sich klar macht wer etwas besitzt und wer etwas kennt. Das ist es vermutlich worauf der Autor hinaus möchte.