spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Laguna"«

Jedoch möchte/kann ich für die organisation nicht die std-Container benutzen, da ich mir einige zusätzliche Funktionen wünsche. So z.B. dass jedes Spielobjekt über seinen Bezeichner identifizierbar ist oder dass Objekte serialisiert werden können, für Speichern/Laden (und einige andere Sachen)

Das kannst du ja trotzdem machen. Die Assoziation mit dem Namen ist schon in std::map eingebaut, zudem kannst du die Funktionalität mit freien Funktionen oder Wrapper-Klassen sehr gut erweitern. Halte ich für die bessere Vorgehensweise als selbst was zu basteln, das einen Grossteil der Funktionalität nur nachbaut – wahrscheinlich sogar schlechter.

Zitat von »"Laguna"«

Mir erscheinen gerade zwei Wege sinnvoll: Entweder ich baue mir einer Vererbungshierarchie auf: "GameObject" und dies als Interface für eine Speicherung.

Alternativ eine Templateklasse, die diese Objekte verwaltet.

Ich habe ehrlich gesagt zu wenig Informationen. Du sagst, du willst ein paar Objekte machen, die du serialisieren und über den Namen ansprechen willst. Aufgrund dessen kann ich noch nicht sagen, was nun geeigneter wäre.

Aber grundsätzlich brauchst du eine Vererbungshierarchie, wenn dir die Beziehung für die Klassen sinnvoll erscheint. Wenn du z.B. sagen kannst, es gibt Spielobjekte wie Gräser, Steine, Gegner, davon kann man eine Gruppe als bewegliche Spielobjekte spezialisieren, welche ihrerseits wieder unterteilt werden können, dann scheint Vererbung naheliegend. Laufzeitpolymorphie kommt auch nicht automatisch mit Vererbung, es muss schon das Bedürfnis vorhanden sein, Objekte über gemeinsame Basisklassenverweise anzusprechen, sonst sind virtuelle Funktionen sinnlos.

Andererseits, wenn du siehst, dass mehrere Klassen sich grundsätzlich vom Aufbau ähnlich sind, sich zum Beispiel in einem Membertyp unterscheiden, aber sich von der Semantik her nicht so nahestehen, können Klassentemplates (nicht direkt Templateklassen!) sinnvoll sein. Gleiches gilt für Funktionstemplates. Das Gemeinsam Ansprechen erfolgt oft mit dem Hintergedanken, dass eine Klasse oder Funktion ein gewisses Interface bereitstellen muss. Mit statischer Polymorphie ist man flexibler, weil keine Vererbungshierarchien erforderlich sind, dafür hat man weniger Möglichkeiten, zur Laufzeit Mechanismen und Funktionalität auszutauschen.

Zudem solltest du nicht denken, dass Polymorphie und Templates sich ausschliessen. Oft kommen die vollen Abstraktionsmöglichkeiten erst zum Zug, wenn man mehrere Konzepte kombiniert.

Zitat von »"Laguna"«

Allerdings kann man sich damit auch recht schnell in Sackgassen manövrieren. Zusätzlich kommt einiges an Tipparbeit auf einen zu, sowie die Performanceeinbußen durch VTables.

Die Performance von virtuellen Funktionen sollte kein ausschlaggebendes Kriterium sein. Die ist in den allermeisten Fällen um Dimensionen weniger kritisch als z.B. Rendering- oder komplexe Rechenvorgänge.

Zitat von »"Nexus"«

Zitat von »"Laguna"«

Allerdings kann man sich damit auch recht schnell in Sackgassen manövrieren. Zusätzlich kommt einiges an Tipparbeit auf einen zu, sowie die Performanceeinbußen durch VTables.

Die Performance von virtuellen Funktionen sollte kein ausschlaggebendes Kriterium sein. Die ist in den allermeisten Fällen um Dimensionen weniger kritisch als z.B. Rendering- oder komplexe Rechenvorgänge.

Da erscheint mir aber das, was Heiko Kalista in seinem Buch darüber sagt, ein wenig anders:
Wenn man ein komplettes Spiel darauf aufbaut, kann das imo nur schiefgehen.
Für einzelne Spielobjekte sieht das natürlich anders aus...

mfg CBenni::O

Zitat von »"CBenni::O"«

Wenn man ein komplettes Spiel darauf aufbaut, kann das imo nur schiefgehen.

Dann müssten in Java alle Spiele von Vornherein zum Scheitern verdammt sein.

Und natürlich wird man auch in C++ nicht daran gehindert, den gesunden Menschenverstand einzusetzen. Hier hat man sogar die Möglichkeit, nur Funktionen virtuell zu machen, die es wirklich sein müssen. Und das sind bei weitem nicht alle - schon mal alle freien Funktionen beispielsweise nicht.

Kannst du mir vielleicht zitieren, was Heiko Kalista in seinem Buch genau sagt?

Zitat von »"Nexus"«

Kannst du mir vielleicht zitieren, was Heiko Kalista in seinem Buch genau sagt?

Ööm...
2. Erweiterte Auflage, Seite 226,
Kapitel 9.9.3 "Vererbung und Performance"

Ich habe das noch nie ausprobiert, wie groß der Unterschied in der Performance ist, ich musste wohl oder übel darauf vertrauen, was Heiko Kalista da sagt, ich wollte mich nur versichern, was daran dran ist, bevor ich virtuelle Funktionen verdamme...

mfg CBenni::O

EDIT: Ja, war eine bisschen unglückliche Formulierung, es kam mir nur so vor, dass so etwas nicht gut sein kann... aber die Irrlicht Engine schafft es auch mit gefühlten 1000 Virtuellen Ableitungen

Zitat von »"Laguna"«

Dann müsste ich als Programmierer ja quasi 2 Interfaces darstellen, eines als richtiges Interface und eines als Template klasse...

Kombination bedeutet eben nicht zwei sich ausschliessende Alternativen. Setze die Konzepte da ein, wo sie sinnvoll sind. Du wirst mit der Zeit merken, dass jedes seinen eigenen Anwendungsbereich hat und beide zusammen sich gut ergänzen und eine ziemliche Abstraktion ermöglichen. Natürlich ist das nicht ganz einfach, wenn man nicht schon eine gewisse Erfahrung hat. Ich würde dir auch gerne spezifische Ratschläge geben, aber da du bezüglich deiner Programmstruktur nicht wirklich konkreter geworden bist, wird das schwierig für mich.

Zähle am besten ein paar zentrale Typen in deinem Projekt auf und beschreibe ihre Beziehungen (nur die allerwichtigsten, damit das Prinzip klar ist). Wenn du willst, kannst du auch deine Vorstellungen einer Implementierung mittels Templates und mittels dynamischer Polymorphie jeweils an einem kleinen Stück Code verdeutlichen. So, dass wir wenigstens einen Anhaltspunkt haben.

Zitat von »"CBenni::O"«

Ööm...
2. Erweiterte Auflage, Seite 226,
Kapitel 9.9.3 "Vererbung und Performance"

Danke, aber ich fragte eigentlich nach einem Zitat, da ich das Buch nicht besitze.

Zitat von »"CBenni::O"«

EDIT: Ja, war eine bisschen unglückliche Formulierung, es kam mir nur so vor, dass so etwas nicht gut sein kann...

Was kann nicht gut sein? Überall virtual hinschreiben wo es hinpasst? Ja, da hast du Recht. Aber ansonsten würde ich nicht zu schnelle Schlüsse ziehen, auch wenn sich Sätze wie "virtuelle Funktionen sind langsam" besonders gut einprägen...

Achso... uff...

Zitat

Vererbung ist eine tolle Sache [...] aber gerade wenn virtuelle Memberfunktionen zum Einsatz kommen, kann das Auswirkungen auf die Performance haben.
Oft wird das unterschätzt [...] Virtuelle Funktionen schleppen verhältnismäßig viel Ballast mit sich herum, was an den internen Abläufen liegt, [...]
Man sieht immer wieder Engines und Sourcecodes, wo es mit der Ableitung und den virtuellen Funktionen einfach übertrieben wurde.

Insgesamt geht das Kapitel ~ 1 Seite lang... Ich denke, dass dies schon nachvollziehbar ist, da auch gute Suchalgorithmen O(n) haben, un vtables müssen, denke ich auch noch sortiert werden ( O(n²), je nach Algo... )

mfg CBenni::O

Das scheint ein wenig übertrieben dargestellt zu sein. Virtuelle Funktionsaufrufe sind wahrscheinlich kaum ein Engpass.

Man sollte nicht gerade bei Hochfrequenten Aufrufen Polymorphie mit dabei haben, aber ansonsten sollte das kaum ein Problem darstellen.

Ja, z.B. wenn man sich ne Klasse bastelt, die alle Objekte vereint (Kameras, Lichter, Modelle, Sprites etc.pp) und dann je nachdem ableitet... sollte man evtl. vermeiden, da diese Klassen dann viele male pro Sekunde aufgerufen werden (oder auch nicht :badgrin: ) und es dann zu merkbaren Leistungseinbußen kommen kann...

Ich persönlich finde die Syntax von abgeleiteten Klassen nicht sonderlich schön, aber das ist geschmackssache

mfg CBenni::O