spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du brauchst eine Instanze nicht auf ihre Basisklasse casten. Das wird automatisch gemacht.
Ich sehe hier aber den fehler, dass du eine Variable in einen Pointer umcastest, was nen bisl komisch ist und nich das ist was du willst oder ?
Fehlt vtl ein "&" vor myElement und second_Element ?

das design an sich finde ich aber OK

Ich würde die Vererbung grundsätzlich nochmals überdenken. Im Allgemeinen wird diese nämlich zu oft eingesetzt.

In deinem Fall würde ich meinen, du fährst besser, wenn du die Grafik von der Logik trennst. Das heisst, Enemy erbt nicht von CSprite und CParticle, weil ein Gegner weder ein Sprite noch ein Partikel ist - sondern nur ein Objekt, das sich bewegen und gewisse Aktionen durchführen kann. Sprite wird erst im Bezug auf die Grafik relevant. Von daher würde ich dir eher raten, eine Klasse für bewegliche Objekte zu erstellen, und dann Spieler, Gegner etc. davon abzuleiten. Eventuell sind da noch genauere Abstufungen möglich (wie z.B. kollidierbares Objekt), das hängt von der gegebenen Funktionalität ab.

Diese Trennung erhöht die Abstraktion und hat dementsprechend den Vorteil, dass nicht jedes Spielelement 1:1 an ein Sprite gebunden ist. Zum Beispiel ist es sinnlos, Sprites für Elemente ausserhalb des Bildschirms zu haben. Oder für mehrere Objekte, die gleich aussehen, jeweils einzelne Sprites. Auf der anderen Seite bist du dadurch auch flexibler, weil die Grafik an einem zentralen Ort (am besten in einer Klasse wie Renderer oder GraphicManager) geregelt ist. Wenn du den sf::RenderWindow:raw()-Aufruf noch kapselst, kannst du zum Beispiel auf Befehl das Zeichnen an- und abschalten.

Ich empfehle dir dann, für die Spielelemente spezifische Funktionen zu machen, z.B.:

Und versuch, nicht so oft mit dem Heap (new) zu arbeiten, wenn möglich (hast du an die deletes gedacht?). Genauso rate ich dir, oft Referenzen statt Zeiger bei der Übergabe zu verwenden und auf Const-Correctness Rücksicht zu nehmen. Wenn eine Funktion am übergebenen Objekt nichts verändert, deklarier es als const. Wenn eine Memberfunktion an der Klasse nichts verändert, mach sie ebenfalls const.

Nexus, du solltest die Eigenheiten von SFML berücksichtigen:

- Draw rendert nichts außerhalb des views.
- Ein Sprite ist bei SFML keine Textur sondern nur ein Objekt mit Größe und Position, dass eine Referenz auf ein Image (eine Textur) haben kann.

Ach ja, da du ja Partikel mit SFML machen willst, kann ich dir ein
Partikelengine anbieten, die auf Opengl basiert ( womit ja auch sfml gemacht ist). Das bedeutet, dass das teil echt schnell ist, was ich gerade bei Partikeln wichtig finde.
Außerdem hat das Teil echt alles was man braucht, von Grvitation bis zu Kollision und wenn das nicht braucht, kann man einfach noch seine eigene manipulations-funktion angeben.

Das Problem ist, dass die Docu nicht mehr ganz stimmt, weil Die ursprünglich
als allgemeine 3d partikel-engine gedacht war, ich sie aber komplett auf sfml umgeschrieben habe, weil die sfml-komponente nicht funktioniert hat
Aber das ist nicht so schlimm, weil im entergebniss hab ich nur die Vektoren verändert (von 3d auf sf::vector2f) und die namespaces hab ich auch ein bisl abgeändert

Also wenn du Interesse hast, schreib mir ne nachricht
( Kannst natürlich auch die eigentliche engine nehmen (Link weiter unten !) )

Hier ein Video, allerdings noch 3d
Screenshoot´s der SPARK Partikelengine (Weiter unten auch die SFML-Komponente

PS: Habe gerade gesehen, dass es jetzt auch ein Tutorial gibt

Zitat von »"K-Bal"«

- Draw rendert nichts außerhalb des views.

Nicht ganz. Ok, die Entscheidung liegt bei OpenGL, welche Pixel gezeichnet werden. Aber es sind nicht wenige Anweisungen, um ein komplettes Sprite zu zeichnen mit allen Transformationen. Diese werden aber in jedem Falle durchgeführt, selbst sich das Sprite ausserhalb des Views befindet. Eine If-Abfrage, ob dieses überhaupt auf dem Bildschirm ist, kann da einiges einsparen.

Zitat von »"K-Bal"«

- Ein Sprite ist bei SFML keine Textur sondern nur ein Objekt mit Größe und Position, dass eine Referenz auf ein Image (eine Textur) haben kann.

Ja, aber was hat das damit zu tun? Tatsache ist, dass ein Sprite nur für die Grafik benötigt wird. Für Spiellogik kann man damit nicht wirklich viel anfangen. Zudem hat ein sf:prite eine Grösse von 196 Bytes, das ist recht viel (zumal man meist nur einen kleinen Teil der Eigenschaften benötigt). Wenn man seine Tilemap oder Partikel auf Sprites basiert, hat man total unnötigen Speicherverbrauch. Genauso unnötig ist er, wenn 30 Objekte 30 Sprites haben, die alle gleich sind.

Unabhängig davon, wie SFML aufgebaut ist und was in den Anfängertutorials steht, kann es Sinn machen, Grafik und Logik zu trennen. Andere Vorteile habe ich ja vorher bereits erwähnt.

Ich verstehe nicht was an einem Sprite pro Objekt schlimm sein soll. Es ist ja nicht ein Image pro Objekt sondern nur ein Sprite. Willst du jetzt für jedes Objekt, dass du renderst dein Sprite bewegen, rotieren und skalieren?

Vlt versteh ich dich nur falsch.

@ 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:
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.