@ physX: Du kannst deine eigene Klasse auch ihre Position speichern lassen. Wenn dir das momentan zu mühsam vorkommt, kannst du es auch vorerst lassen, aber behalt die Möglichkeit doch im Hinterkopf.
@ K-Bal: Wie so oft kann man nicht einfach sagen, 1 Sprite pro Objekt sei grundsätzlich schlecht, aber auch nicht grundsätzlich gut. Ich habe bisher eben die Erfahrung gemacht, dass ich generell flexibler bin, wenn ich die Grafik separat handhabe und klar von der Logik abtrenne.
Man muss nicht unbedingt ein einziges Sprite haben, sondern kann z.B. pro unterschiedliches Objekt eins haben und alle Sprites in einer Map speichern. Die Position und Rotation ändern sich meistens sowieso jedes Frame, und selbst abgesehen davon sind die einzelnen Zuweisungen an Variablen nicht wirklich rechenzeitintensiv. Im Gegenzug kannst du dir Rechenzeit sparen, wenn du Spiellogik-Objekte von Sprites trennst: Da diese eine meist kleinere Grösse haben, werden Kopien schneller durchgeführt, was sich zum Beispiel in Containern positiv auswirken kann. Zudem entfallen auch Konstruktion, wenn ein neues Spielobjekt entsteht, sowie Destruktion, wenn eines verschwindet. Indem du die beiden Dinge unabhängig voneinander machst, hast du viele Vorteile. Performance ist dabei für mich nicht einmal das Entscheidende. Im Extremfall (Tilemap oder Partikel) kann sie allerdings schon entscheidend werden, wobei dann möglicherweise auch der Speicherverbrauch kritisch wird.
SFML hat bereits einen Schritt in diese Richtung getan, indem es Sprites von Images getrennt hat. Ich kann diese Abstraktion noch vergrössern, indem ich Logikobjekte von Sprites trenne. Schau doch nur mal, wie viele Attribute sf:
prite besitzt:
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
ResourcePtr<Image> myImage;
IntRect mySubRect;
bool myIsFlippedX;
bool myIsFlippedY;
Vector2f myPosition;
Vector2f myScale;
Vector2f myOrigin;
float myRotation;
Color myColor;
Blend::Mode myBlendMode;
mutable bool myNeedUpdate;
mutable bool myInvNeedUpdate;
mutable Matrix3 myMatrix;
mutable Matrix3 myInvMatrix;
|
Wie viele davon brauchst du tatsächlich, um einen Gegner zu beschreiben?
Die Variablen myScale oder myBlendMode sind wohl in den meisten Fällen auf den Defaultwert gesetzt. Wenn du wirklich nur einen Gegner mit notwendigen Eigenschaften hast, fallen dir zum Beispiel auch andere Aktionen wie Schreiben/Lesen von Dateien leichter, da du gleich alle relevanten Daten im Überblick hast. Ausserdem kannst du auch zusätzliche grafische Eigenschaften (wie z.B. Animation) direkt in eine Draw-Kapselfunktion einbauen, die ein sf:
prite selber nicht kennt.