SFML Einsteiger-Tipps
Aus Spieleprogrammierer-Wiki
(Unterschied zwischen Versionen)
| [gesichtete Version] | [gesichtete Version] |
(Die Seite wurde neu angelegt: „ Beim Lernen von C++ wird unter anderem gern auf SFML zurückgegriffen, weil man damit spielerisch die Welt von C++ erkunden kann und nicht auf die Konsole angewi…“) |
(Rückgabewert vergessen) |
||
| Zeile 51: | Zeile 51: | ||
playerTemp.setPosition(0, 0); | playerTemp.setPosition(0, 0); | ||
playerTemp.setHealth(health); | playerTemp.setHealth(health); | ||
| + | return playerTemp; | ||
} | } | ||
... | ... | ||
| Zeile 58: | Zeile 59: | ||
</sourcecode> | </sourcecode> | ||
Auf den ersten Blick sieht das gar nicht so schlecht aus. Man hat eine Funktion, die schön gewisse Logik kapselt. Das Ergebnis ist ein Absturz des Programms. Was ist passiert? Die Spieler wurde korrekt in createPlayer erstellt und gewisse Initialwerte zugewiesen. Dann wurde er zurückgegeben und zugewiesen. Dabei wird allerdings wieder der Kopierkonstruktor von playerTemp gerufen. Den kennen wir schon aus dem vorherigen Beispiel. Der Kopierkonstruktor macht jedoch eine wichtige Sache nicht, er sagt dem Sprite nicht, dass es die kopierte Textur verwenden soll. Das Sprite von player1 zeigt also ebenfalls auf die originale Textur von playerTemp. Wird die Funktion verlassen und player neu zugewiesen, wird allerdings die alte Player-Instanz (playerTemp), nicht mehr gebraucht. Sie wurde ja kopiert in player1. Also wird sie zerstört. Und mit ihr auch die original Textur aus playerTemp. Das beutet, dass das Sprite in player1 nun eine Textur referenziert, die gar nicht mehr existiert. Zugriffe auf nicht existente Objekte verursachen diverse Fehler. Der Crash ist hier noch der beste Fall. Richtig fies ist, dass der Crash nicht unbedingt beim Aufruf von player.draw() erfolgen muss. Er kann auch wesentlich später erst eintreten, wo die Ursache des Fehlers nicht mehr nachvollziehbar ist. | Auf den ersten Blick sieht das gar nicht so schlecht aus. Man hat eine Funktion, die schön gewisse Logik kapselt. Das Ergebnis ist ein Absturz des Programms. Was ist passiert? Die Spieler wurde korrekt in createPlayer erstellt und gewisse Initialwerte zugewiesen. Dann wurde er zurückgegeben und zugewiesen. Dabei wird allerdings wieder der Kopierkonstruktor von playerTemp gerufen. Den kennen wir schon aus dem vorherigen Beispiel. Der Kopierkonstruktor macht jedoch eine wichtige Sache nicht, er sagt dem Sprite nicht, dass es die kopierte Textur verwenden soll. Das Sprite von player1 zeigt also ebenfalls auf die originale Textur von playerTemp. Wird die Funktion verlassen und player neu zugewiesen, wird allerdings die alte Player-Instanz (playerTemp), nicht mehr gebraucht. Sie wurde ja kopiert in player1. Also wird sie zerstört. Und mit ihr auch die original Textur aus playerTemp. Das beutet, dass das Sprite in player1 nun eine Textur referenziert, die gar nicht mehr existiert. Zugriffe auf nicht existente Objekte verursachen diverse Fehler. Der Crash ist hier noch der beste Fall. Richtig fies ist, dass der Crash nicht unbedingt beim Aufruf von player.draw() erfolgen muss. Er kann auch wesentlich später erst eintreten, wo die Ursache des Fehlers nicht mehr nachvollziehbar ist. | ||
| + | |||
=== Kopierte Texturen als Fehler deklarieren === | === Kopierte Texturen als Fehler deklarieren === | ||
Damit solche Fehler nicht unterlaufen können und bei der versehentlichen Kopie einer Textur gleich eine Fehlermeldung kommt, bietet es sich an eine eigene Textur-Klasse zu verwenden: | Damit solche Fehler nicht unterlaufen können und bei der versehentlichen Kopie einer Textur gleich eine Fehlermeldung kommt, bietet es sich an eine eigene Textur-Klasse zu verwenden: | ||
Aktuelle Version vom 2. November 2015, 14:05 Uhr
Klicke hier, um diese Version anzusehen.
