Pointer class soll sich selbstständig löschen.
-
Wie, so? Also mit meinem Code wird das Löschen automatisiert, das erzeugt keine Speicherlecks.
Wenn Du ein Partikel erzeugst, das sich selbst löscht, musst Du jedenfalls ganz schön aufpassen, das kann ich nicht empfehlen. Denn ich schätze Mal, in jedem Frame wird vom Partikel eine Update-Methode oder so aufgerufen? Dann brauchst Du ja sowieso einen Container von Partikeln. Wer auch immer von außen auf das Partikel zugreift, muss das Löschen eben mitkriegen. Und das klappt nicht, wenn sich das Partikel selbst löscht, außer das Löschen wird eben von außen angestoßen und dann nutzt man doch wieder besser Smartpointer...
-
Sicher, dass jedes einzelne Partikel dynamisch angefordert werden soll? Das kann bei vielen kurzlebigen Partikeln zu einem echten Performance-Bottleneck werden.
Eisflamme, so zu iterieren ist ebenfalls langsam, da
vector::erase()alle nachfolgenden Elemente verschiebt. Ich würde eherstd::remove_if()verwenden.
-
Ja, das war jetzt nicht groß durchdacht. Man nutzt ja für Partikelsysteme gerne auch Mal eigene Allokatoren oder Pools, das wäre dann wohl besser.
Auch beim erase hast Du völlig recht.
-
std::remove_if löscht aber die Elemente nicht, sondern schiebt sie nur ans Ende. Um sie wirklich zu löschen wäre ja dann noch immer ein erase notwendig.
Ist das erase-remove-idiom da wirklich im Vorteil?
-
Ja, weil die Verschiebung der danachfolgenden Elemente der Haupt-Performance-Fresser ist. erase-swap-Idiom (wie auch immer es genau heißt) nutzt eben nur den swap und ein erase mit konstanter Laufzeit.
-
Eisflamme schrieb:
Man nutzt ja für Partikelsysteme gerne auch Mal eigene Allokatoren oder Pools, das wäre dann wohl besser.
Man kommt schon mit
std::vector<Particle>recht weit. Gerade mit seiner Allokationsstrategie hat man kaum noch Allokationen, nur noch Kopien.llllll schrieb:
Ist das erase-remove-idiom da wirklich im Vorteil?
Ja, weil das
erase()dann einmal am Schluss aufgerufen wird -- die Elemente werden also in linearer Zeit entfernt. Wenn manerase()in jeder Iteration aufruft, hat man quadratische Laufzeit.Eisflamme schrieb:
Ja, weil die Verschiebung der danachfolgenden Elemente der Haupt-Performance-Fresser ist. erase-swap-Idiom (wie auch immer es genau heißt) nutzt eben nur den swap und ein erase mit konstanter Laufzeit.
Meinst du
swap()-and-pop_back()? Das ist bei Partikelsystemen je nachdem ungünstig, da die Reihenfolge geändert wird. Wenn man keinen Depth-Buffer hat, werden die Partikel also in anderer Reihenfolge gezeichnet, was merkwürdig aussehen kann.
-
Hey, Ich habe mein Problem fürs erste gelöst und bin sehr zufrieden, danke für die tollen Ratschläge.
Jetzt habe ich noch ne frage, die Sprites sollen sich in die Richtung bewegen in die sie ausgerichtet sind, tun sie aber nicht. Es sieht zwar aus wie eine nette kleine Explosion ^^ aber halt mit verdrehten Bildchen.
_AllParticle[i]._Position.x += sin(_AllParticle[i]._Sprite.getRotation()) * _AllParticle[i]._Speed; _AllParticle[i]._Position.y += cos(_AllParticle[i]._Sprite.getRotation()) * _AllParticle[i]._Speed;
-
Bezeichner, die mit Unterstrich und Grossbuchstaben beginnen, sind reserviert. Du darfst diese nicht verwenden!
Ansonsten, bringst du Grad und Bogenmass durcheinander?
-
Ja ok, ich werde meine Schreibeisse überarbeiten
Der Code denn ich gepostet habe ist alles was ich verwende. Keine vorherige berechnung. Rotation ist ein zufallswert zwischen 0 &360.
-
Ja, eben.
sin und cos brauchen aber Bogenmaß und nicht Gr
ad.
-
Ok dann schau ich mal. Seit dem ich angefangen habe zu Programmieren fällt mir mein Mathe Defizit erst richtig auf
