Hi^^

Ich wusste nicht genau, wie ich nach einem ähnlichen Thema suchen soll, deswegen bitte ich um einen kleinen Hinweis wenn es dieses Thema schon gibt, und schwups schau ich mich nochmal um^^

Ich bastel momentan an einem kleinen Shooter über den ich bereits in meinem Vorstellugsthreat berichtet habe. In früheren Versionen davon habe ich für jedes Geschoss, das ein Spieler oder ein NPC schießt, ein Objekt erschaffen (zb TBullet). Nun wird im Partikeltutorial empfohlen, nicht für jeden Effekt ein eigenes Objekt zu erschaffen, sondern aus Speichergründen einen Record zu erstellen (ich bitte um Verzeihung sollte dies nicht der Fachbegriff sein, und um Korrektur^^) und die Effekte in einer Schleife abzulaufen und zu verwalten. Meine Frage nun: Ist es sinvoll, das mit allem möglichen zu tun? Wie groß ist der Vorteil? Es gibt in meinem Spiel sehr viele verschiedene Aten von Geschossen, die nicht alle linear fliegen, die verschiedene optische Effekte haben, explodieren oder nicht, etc, sodass ich entweder für verschiedene Arten verschiedene Listen erstellen müsste oder einen sehr vollgestopften Record erschaffen müsste.

Lohnt sich das, oder mache ich mir damit nur unnötige Probleme?

Gruß, Robin

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,

Ich würde für jede Instanz einer Waffe im Spiel eine Instanz für die Geschosse dieser Waffe verwenden. Diese Instanz verwaltet dann also alle Geschosse die von dieser Waffe geschossen werden. Bei einer Minigun hättest du dann 100 gleichartige Geschosse (Records) die alle von einer Geschoss-Klasse verwaltet werden.


Es geht darum Methodenaufrufe und auch Speicher zu sparen. Eine Klasse braucht immer noch ein wenig zusätzlichen Speicher für die Polymorphie. Bei 10.000 Partikeln sparst du natürlich wesentlich mehr...

_________________
Yeah!

Um den Rechenaufwand ein bischen zu redusieren würde ich erstmal ein array beim start vor initialisieren.
Ob es nun ein Record oder Klasse ist macht nun nicht mehr viel aus, der Konstrukturor und Destruktor werden ja nun nicht mehr aufgerufen und das zusätzliche push Argument beim aufrufen von Klassenmethoden ist nicht wirklich bemerkbar(bei 32Bit in Delphi 4Byte stack push und bei c++ mit & als Parameter auch). Es gibt unterschiedliche Projektielarten, einige sind schneller andere langsamer und einige sehr schnell. Einige Spiele machen für schnelle Projektiele einfach nur ein Raycast Intersection und setzen am ersten Kollisionspunkt ein Partikelemitter mit entsprechendem Reflektionswinkel. Andere Games haben langsamere Geschosse, welche noch sichtbar sind und ein hellen streifen hinter sich her ziehen -_- Filmindustrie sei dank. Das größte Problem bei Projektielen sind die Geschwindigkeit und Häufigkeit, erstens kann wenn man die falsche implementierung nutzt schnell Fehler verursachen und zweitens kann auf die Performance schlagen, wenn man es falsch macht.

Ich würde eine Klasse für Projektiele anlegen.


Das wäre eine Lösung die ein Puffern erstellt und in größeren Intervallen weitere Slots erstellt.
So werden zur Laufzeit keine Konstruktoren,Destruktoren,Getter,Setter,new und free Funktionen aufgerufen(macht klassen langsam in massen).
Die Kugel weiß alles, was sie wissen muss und lässt die die Möglichkeiten von Klassen.
Der Manager schuppst die Projektile rum(egal ob über Physiksystem oder einer kleinen eigenen Routine) und durch die Ressourcen(Model,Sound,Partikelemitter) und dem Projektiltyp kann er fest stellen, welchen Partikelemitter er aktivieren muss und welcher Sound abgespielt werden soll.
Draw und Update sind mit Absicht getrennt, da man Projektile auch verarbeiten muss, wenn man sie nicht sieht bzw. auch verarbeiten muss, wenn die Grafikkarte zu langsam ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

danke für die antworten

das mit mehreren schusstypen und entsprechend vielen records hab ich mir auch schon überlegt, hab mich jetzt aber für eine liste mit einem umfangreichen typen entschieden. das ist weniger schreibarbeit (dafür komplizierter) und sehr variabel, wenn ich das fertig hab, ist es noch leichter als eh schon, neue waffen bzw angriffe zu entwerfen.

ich danke trozdem auch für den vorschlag einfach keine creates, frees etc zu verwenden, diese methode hab ich mir nie angeschaut aber werd überlegen ob das an anderer stelle sin macht. ich denke ich hab also was gelernt^^

gruß, robin

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,