STL für Spiele, ja oder nein? [geschlossen]

144

Jede Programmiersprache hat ihre Standardbibliothek mit Containern, Algorithmen und anderen nützlichen Dingen. Bei Sprachen wie C #, Java und Python ist es praktisch undenkbar, die Sprache ohne ihre Standardbibliothek zu verwenden.

Bei vielen C ++ - Spielen, an denen ich gearbeitet habe, haben wir entweder die STL überhaupt nicht verwendet, einen winzigen Bruchteil davon verwendet oder unsere eigene Implementierung verwendet. Es ist schwer zu sagen, ob dies eine fundierte Entscheidung für unsere Spiele war oder nur aus Unkenntnis der STL.

Also ... passt die STL gut oder nicht?

herrlich
quelle
14
Die EASTL ist eine gute Lektüre open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Matias Valdenegro
1
Ja, das ist die, die ich mit "benutzte unsere eigene Implementierung" gemeint habe. :)
Munificent
3
Wenn Sie die Möglichkeit haben, Best of Game Programming Gems zu finden und zu kaufen, tun Sie es. Es gibt einen Artikel mit dem Titel "Using the STL in Game Programming" von James Boer, ArenaNet, in dem er sich wirklich gut mit der STL auskennt.
Chiguire
Eigentlich ist es durchaus denkbar, Java ohne seine Standardbibliothek zu verwenden. Es heißt J2ME: p
Bart van Heukelom
1
Gute Frage!
Alan

Antworten:

191

Als ich in der professionellen Spieleentwicklung arbeitete, war STL zu unreif und aufgebläht. Aber das war vor> 10 Jahren.

Jetzt arbeite ich in der Militärsimulation, die noch strengere Leistungsanforderungen hat (so wie die Framerate niemals unter einige FPS fallen kann). In der militärischen Simulation wird STL überall verwendet.

Einige der Leute, die Ihnen raten, STL nicht zu verwenden, argumentieren, dass es nicht immer die perfekte oder sogar beste Lösung für das Problem ist. Aber das ist keine Antwort auf die Frage. Die Frage sollte lauten: Stimmt etwas nicht mit der Verwendung von STL in Spielen? Ich würde nein sagen, STL ist die meiste Zeit eine bessere Implementierung als die, die sich ein Benutzer selbst einfallen lassen würde.

Stellen Sie einfach sicher, dass Sie wissen, wie die STL verwendet wird, und verwenden Sie sie in Ihrem Spiel. Lesen Sie einige Bücher und sehen Sie sich den Implementierungscode in der von Ihnen verwendeten STL an.

kevin42
quelle
49
Das ist ein ziemlich solider Rat. Das Mem "STL is slow" ist seit mindestens fünf Jahren nicht mehr gültig und wahrscheinlich auch nicht mehr. Es wird weiterleben, ähnlich wie der Unsinn "Java ist langsam" und ".NET ist langsam", bis allen klar wird, dass dies nicht mehr der Fall ist. Mit der STL können Sie bessere Programme schreiben. Ich würde so weit gehen zu sagen, dass es in den meisten Fällen (abgesehen von den 0,1% irgendwo) unverantwortlich ist, es nicht zu verwenden. (Die Behauptungen, dass es nicht zu einer bestimmten Problemdomäne passt, sind oft eher ein Hinweis auf die Art und Weise, wie das Problem angegangen wurde, nicht auf die STL selbst.
Korrigieren Sie
5
@ Ed Ropple: Ich denke, das Problem ist nicht, dass STL nicht zu einem bestimmten Problem passt. Das Problem ist, dass zu viele Probleme passen, was den Code zu komplex macht. Es ist beängstigend, wie viele Menschen STL überbeanspruchen, und ich denke, dies ist einer der Gründe, warum so viele (auch ich) es überhaupt nicht benutzen. Wie in einem Beispiel, das ich vor nicht allzu langer Zeit gesehen habe, lautete die Frage, wie man aus drei Zahlen die größte herausholt. Eine der Antworten bestand darin, sie in einen std :: vector und dann in std: sort zu verschieben. Das zwingt definitiv zu einer Lösung, die für ein sehr einfaches Problem nicht notwendig ist.
Simon
22
@ Simon: Bei allem Respekt ist das letzte Beispiel ein Zeichen extremer Ratlosigkeit und hat nichts mit STL zu tun ... diese Person würde dasselbe in jeder anderen Sprache mit Listen tun, die sortiert werden können. Es ist sein Denken, das gebrochen ist.
ggambett
@EdRopple versucht, einen STL-Parser für PPM-Bilddateien zu implementieren (insgesamt weniger als 100 Codezeilen, wenn nur P6 oder P3 als Ziel angegeben werden). Die Hälfte des resultierenden Codes dient nur zum Überspringen von Kommentarzeilen, da STL nicht etwa if(stream.nextCharacter() == '#') stream.skipLine();
Folgendes
@DarioOO Ich kenne das Dateiformat nicht, aber dafür sind Stream-Adapter und Filter gedacht. Ich habe diesen Kommentar vor fünf Jahren geschrieben (und er kommt gelegentlich wieder!), Aber heutzutage schreibe ich über alles, was in einem funktionalen, auf Transformationen basierenden Stil und Themen wie dem von Ihnen nicht super, super-perf-kritisch ist beschreibe fallen aus dem problem. Die Zeilenzahl ist mir eigentlich egal (und Sie sollten es auch nicht tun), mir geht es um die Richtigkeit der Implementierung, dann um die Klarheit, dann um die Leistung und dann um Dinge wie die Codelänge.
Ed Ropple
63

Ich würde sagen, dass es eine bessere Idee ist, die STL zu verwenden, wenn Sie nicht genau wissen , warum Sie sie nicht verwenden möchten.

Das ist das Besondere an der STL: Sie wird von Menschen entwickelt, die schlauer sind als Sie. Das soll nicht anstößig sein oder so, es ist nur so, dass die STL von Leuten entwickelt wird, deren Arbeit tatsächlich die STL erstellt. Es wird ungefähr so ​​schnell sein, wie es die Plattform zulässt, und es wird im Allgemeinen viel robuster sein als eine selbst erstellte Lösung (und dies sollte ebenso ein Problem sein, wenn Sie sich nicht mehr Gedanken über die Geschwindigkeit machen - weil Ihr Spiel dies erfordert Robustheit ist weitaus wichtiger als Geschwindigkeit, letztere ist ohne erstere bedeutungslos).

Die Beschwerden, dass die STL einen "engen Blick auf die Welt" erzwingt, kommen mir ein wenig albern vor. Das sind Container. Sie haben eine begrenzte Anzahl von Operationen, da Container eine begrenzte Anzahl von Operationen haben. Was machst du, das damit nicht einverstanden ist?

Ed Ropple
quelle
4
Ich denke nicht, dass jemand rechtfertigen muss, warum er STL nicht verwenden sollte. Stimmen Sie auch nicht mit dem ganzen Argument überein, dass "es verwenden soll, weil es schlauer ist als Sie". STL wurde für eine bestimmte Sicht auf eine Problemdomäne entwickelt, nicht nur für Container, dh Algorithmen, Allokatoren, Iteratoren, Merkmale usw. Das ist fair genug, aber es ist nicht die einzige Sichtweise auf diese Problemdomäne
zebrabox
2
Sie möchten also lieber selbst erstellten Code als allgemein getesteten, stark robusten Code? Die Problemdomäne ist nicht allzu unterschiedlich von Projekt zu Projekt (abgesehen von vielleicht eingebetteten Projekten - sogar Konsolen haben heutzutage anständige STL-Implementierungen!). Unabhängig vom Spiel ist Ihr Problem nicht so unterschiedlich, und wenn Sie etwas herstellen, das Sie versenden möchten, haben Sie die implizite Verantwortung, robusten Code zu schreiben. Wird eine Neuimplementierung des Rades zu einer besseren Robustheit und Flexibilität führen? Ich neige zu "nein". Dass es nicht der "einzige Weg" ist, bedeutet nicht, dass es im Allgemeinen nicht überlegen ist.
Ed Ropple
20
Ich würde sagen, dass es bei gamedev darum geht , Spiele zu machen , aber OK. Wenn Ihre Annahmen so schlecht sind, dass Sie sich mit dieser Art der Ressourcenzuweisung auseinandersetzen, müssen Sie sie zurücknehmen und neu bewerten. Aber Sie können erstaunlich schnelle Anwendungen erstellen, die die STL genauso gut verwenden - und mit Sicherheit jede andere Implementierung -, wenn Sie tatsächlich wissen, was Sie tun . Erfahren, was Sie tun> Frachtkultivierung einer Ablehnung der STL. Niemand sagte, die STL sei immer die beste Antwort. Was ich sage ist, dass, wenn Sie nicht herausfinden können, warum es nicht der beste Kurs ist , Sie die STL verwenden sollten.
Ed Ropple
11
Ich finde es überhaupt nicht provokativ - es ist so formuliert, dass es jemandem in Erinnerung bleibt, aber es ist eine äußerst konservative und direkte Haltung. Kurz gesagt: Die Leute, die die STL entwickeln, sind kenntnisreicher und besser ausgerüstet als jemand, der feststellt, dass sie diese Frage stellen müssen. Wenn Sie jemanden fragen müssen, ob die STL angemessen ist oder nicht, fehlt Ihnen mit ziemlicher Sicherheit das domänenspezifische Wissen, um eine hausgemachte Lösung angemessen vorzubereiten.
Ed Ropple
4
"Es wird ungefähr so ​​schnell gehen, wie es die Plattform zulässt". Dies ist eine definitive Unwahrheit, da sich viele Compiler-Anbieter nicht die Mühe machen müssen, die STL so umzuschreiben, dass sie tatsächlich die meiste Leistung aus der jeweiligen Architektur herausholt. STL übernimmt keinerlei Garantie für die Leistungsmerkmale, mit Ausnahme von Big O. O kann jedoch so effizient oder ineffizient sein, wie der Compiler-Hersteller dies wünscht.
Kaj
35

Ich habe sehr wenige Gründe gesehen, die STL nicht für Spiele zu verwenden.

Viele Leute wissen dies nicht, aber Sie können benutzerdefinierte Zuordnungen für Ihre STL-Containerklassen schreiben. Allokatoren sind im Grunde Richtlinienklassen, die Sie in Ihre Vorlagen übergeben, um zu bestimmen, wie Zuweisungen durchgeführt werden. Mit diesen können Sie normalerweise alle Speicherprobleme umgehen, die auf der Plattform Ihrer Wahl problematisch sind.

Wenn Sie die STL verwenden und dumme Dinge wie Zuordnungen von Zeichenfolgen zu großen Typen ohne Zeiger ausführen, haben Sie natürlich größere Probleme.

Tetrade
quelle
Tatsächlich ist die Verwendung großer Nicht-Zeigertypen in Maps ein guter Anwendungsfall, da stdlib-Maps die Anforderung haben, Iteratoren nicht ungültig zu machen, wodurch die Implementierung zur Verwendung von Zeigern und individuell zugewiesenen zugeordneten Elementen gezwungen wird. Die beste Lösung für Spiele ist es, google::sparse_mapeigene Spiele zu verwenden oder zu schreiben.
v.oddou
Warum nicht dichte Karte?
GameDeveloper
23

Die Standard-STL weist eine Reihe von Problemen auf, die die Verwendung mit Spielen erschweren, insbesondere im Hinblick auf die Speicherausrichtung.

Eine angepasste Variante wie die EA STL wurde speziell für Spiele entwickelt und verbessert die Speicherleistung und die Benutzerfreundlichkeit der Konsole erheblich. Es wurde 2016 unter einer BSD-3-Klausel mit einem Repository auf GitHub zu Open Source .

Ben Zeigler
quelle
19
Probleme mit der Speichernutzung und den Spielen von STL können normalerweise mit benutzerdefinierten Zuweisungsklassen behoben werden. In der Tat war unsere "benutzerdefinierte" std::vectorVektorklasse in meinem vorherigen Job nur eine dünne Hülle , die den Standardzuweiser überschrieb.
Blair Holloway
1
@Blair Holloway: "Die benutzerdefinierten Allokatoren sind klassenbasiert und nicht instanzbasiert. Allokatoren sind erforderlich, um Objekte zu konstruieren und zu zerstören sowie um sie zuzuordnen. Dies erzwingt das Mischen von zwei separaten Konzepten: Allokation und Konstruktion. Dies sind nur einige davon die probleme mit stl-allokatoren leider. " Die EA STL gibt mehrere weitere gültige Gründe an, warum die STD-Allokatoren schlecht sind. Es geht nicht nur darum, ob sie überschrieben werden können oder nicht.
Simon
@ Simon - Ich werde nicht argumentieren, dass das STL-Zuweisungssystem perfekt ist, weil es nicht ist. Wir haben lange gebraucht, um eine Lösung zu finden, die funktioniert. Was ich sagen will ist , dass in einigen Fällen, es ist möglich , eine praktikable, Spielfreundliche Lösung mit STL und eine wenig Arbeit mit benutzerdefinierten Verteilern zu erhalten.
Blair Holloway
@ Simon - Um es näher zu erläutern: Die STL ist zwar umständlich, aber ein sehr gut getesteter und fehlerfreier Code. Wenn Sie es verwenden können, sparen Sie Arbeitsstunden beim Debuggen einer benutzerdefinierten Lösung. Mein jetziger Job meidet die STL zugunsten von selbst gebrauten Allokatoren, und ich musste einige Zeit damit verbringen, diesen Code zu debuggen und umzugestalten, da er nicht den gleichen Reifegrad aufweist wie die STL.
Blair Holloway
1
@Simon: Ich bin ein bisschen zu spät zur Party hier, aber ich bin gespannt, ob du ein konkretes Beispiel dafür geben würdest, was du damit meinst. Was ist ein gutes Beispiel für die Lösung eines bestimmten Problems auf eine Weise, die mit der STL nicht effizient gelöst werden kann?
Gewinnspiel
21

Hier ist, was Mike Acton (Engine Director bei Insomniac Games von Spyro the Dragon, Ratchet & Clank und Resistance Fame) dazu zu sagen hatte, als er hier gefragt wurde . Beachten Sie, dass er sowohl zu STL als auch zu Boost im Allgemeinen befragt wurde, was die Verwendung im Spiel betrifft.

STL / Boost, gehört es zu Gamedev? Wenn nur Teile davon, welche?

Du fragst hier nach zwei verschiedenen Dingen, oder? STL und Boost getrennt. Aber meine Antwort ist die gleiche: Es ist nichts Falsches an einer von beiden, aber ich rate von ihrer Verwendung ab. Die Verwendung von entweder ermutigt die Menschen zu passen , eine Lösung für ein Problem , anstatt die Suche nach einer Lösung für ein Problem. Die Lösung sollte immer für die vorliegenden Daten und die Einschränkungen der Hardware usw. geeignet sein. Sowohl STL als auch Boost haben eine extrem enge Sicht auf die "Welt" und ihre angemessene Verwendung ist begrenzt. Wirklich, ich entmutige sie, weil sie Programmierer auf Anhieb in die falsche Richtung führen. Ich sage oft, wenn Sie das Gefühl haben, eines von beiden zu brauchen, verstehen Sie das Problem, das Sie haben, wahrscheinlich nicht wirklich.

Mir ist auch aufgefallen, dass die meisten professionellen Spieleentwickler eher nach C streben als nach C ++.

Keyframe
quelle
18
Ich bin nicht einverstanden mit dem Streben nach mehr C. Die überwiegende Mehrheit der Spieleentwickler sowie SDK-Autoren verwenden C ++. Tatsächlich war der letzte große C-Benutzer id und sogar Carmack ist jetzt zu C ++ übergegangen ...
Goz
82
Mr. Actons Kommentar scheint lückenhaft zu sein. Im Allgemeinen ist die STL eine gute Lösung für diese Probleme. Wenn Sie versuchen, etwas so zu tun, dass der STL-Ansatz "falsch" zu sein scheint, ist es wahrscheinlich eine gute Idee, Ihren Ansatz neu zu bewerten und zu prüfen, ob Sie ihn tatsächlich auf intelligente Weise durchführen. Nach meiner Erfahrung sind Sie es meistens nicht. (Es ist immens klüger, IMO, ein Problem zu lösen, indem man es im Zusammenhang mit Ihren Werkzeugen versteht, als Ihre Werkzeuge wegzuwerfen, nur um es von Grund auf neu zu machen.)
Ed Ropple
50
Meine Erfahrung mit STL war fast entgegengesetzt. Es ist effizient und zeitsparend. Wenn Sie das Bedürfnis haben, Ihre eigene Vorlagenbibliothek oder Containerbibliothek zu rollen, ist das in Ordnung. Aber tun Sie nicht so, als wäre der STL (oder Boost) schlecht. Ich habe STL ausgiebig auf kommerziellen iPhone-, Nintendo DS-, Wii-, PC-, Mac- und Xbox-Spielen verwendet. Jedes Mal, wenn ich gezwungen wurde, die "bessere" Bibliothek eines anderen zu benutzen, habe ich festgestellt, dass sie fehlt und fehlerhaft ist.
Verlosung
5
Es funktioniert auf dem DS genauso gut wie auf jeder anderen Plattform, auf der ich es verwendet habe. Ich habe STL in der gesamten Benutzeroberfläche und im AI-Code verwendet. Das Spiel war ds.ign.com/articles/832/832147p1.html . Ich arbeitete in einem kleinen Studio, das zu Amaze gehörte, das zu Foundation 9 gehörte.
Gewinnspiel
7
Mike dreht sich alles um Daten. Ein Blick auf die Daten legt die beste Methode zur Transformation der Daten nahe. Wenden Sie es in großem Maßstab an und Sie haben Programmierung. In diesem Zusammenhang macht seine Kritik viel Sinn. STL (und Entwurfsmuster) legen nahe, dass wir nicht die Daten untersuchen, um eine Lösung zu finden, sondern die Lösungen in unserer Trickkiste, um eine Lösung zu finden, die mit den Daten funktioniert. Ich möchte nicht für Mike sprechen, aber ich glaube, er würde vorschlagen, dass diese Herangehensweise an das Problem verkehrt ist und möglicherweise zu ineffizienten oder aufgeblähten Lösungen führen kann.
Dan Olson
19

Wenn Sie feststellen, dass Sie etwas, das bereits in der STL vorhanden ist, aus irgendeinem Grund umschreiben, hören Sie auf . Verwenden Sie die STL.

Die STL wurde über Jahre von Analyse und Zeit optimiert und es ist sicher, dass Sie wahrscheinlich nicht etwas schreiben werden, das effizienter ist. Das heißt nicht, dass Sie STL verwenden sollten, wenn eine einfachere Lösung möglich ist (dh wenn Sie ein Array verwenden, dessen Anzahl bekannt ist, nicht eine stl :: list), aber wenn Sie eine eigene Implementierung einer Map schreiben ( die grundlegende Datenstruktur, nicht eine Spielweltkarte), machst du es falsch.

Ricket
quelle
7
map <> ist so gut wie nie das, was Sie für Speicher oder CPU-Effizienz im Kontext eines Spiels verwenden möchten. hash_map <> ist fast immer eine bessere Wahl, obwohl die Leistung von hash_map stark vom Hersteller abweicht. Wenn Sie ein Spiel erstellen, das entweder für die Konsole oder für skalierbare Netzwerkfunktionen gedacht ist, kann STL für Ihre Zwecke absolut zu langsam oder zu aufgebläht sein.
Ben Zeigler
3
unordered_map <> ist jetzt allgemein verfügbar und stellt im aktuellen TR1-Entwurf äußerst strenge Leistungsanforderungen. (Ich denke, bis zu dem Punkt, an dem es zu einer Überspezifikation kommt - es verbietet sogar offenes Hashing, und obwohl dies normalerweise langsamer ist, denke ich nicht, dass es durch den Standard komplett verboten werden sollte.)
5
Die AWL bietet sowohl Algorithmen als auch Container an. Es gibt nie einen Grund, die Standardversion eines Algorithmus nicht zu verwenden. std::sortVerwendet zum Beispiel im Allgemeinen Introsort darunter, unglaublich schnell und komplex genug, dass Sie es nicht selbst tun möchten.
deft_code
Die Wahrheit ist, dass unordered_mapentweder C ++ 11 oder Boost beide zu langsam sind. Was Sie wollen, ist eine offene Adress-Hash-Map wie google :: sparse_map oder Ihre eigene.
v.oddou
16

Passt STL gut zu Spielen? Bestimmt. Spiele sind komplexe Softwarekomponenten. Die STL bietet Funktionen, mit denen die Komplexität verwaltet werden kann.

Passt es gut zu Ihrer Plattform? Nicht unbedingt. Wenn Sie für eine Konsole schreiben, müssen Sie sehr vorsichtig mit der Speicher- und Cache-Nutzung umgehen. Die STL macht dies nicht sehr einfach.

Ich denke, dass wir "Spiele" allzu oft mit "Hochleistungs-Echtzeitspielen, die auf eingebetteter oder maßgeschneiderter Hardware laufen" verwechseln, aber es ist wichtig, eine Unterscheidung zu treffen. Wenn Sie ein Windows-Spiel schreiben, das nicht versucht, im Vollbildmodus mit einer konstanten Geschwindigkeit von 60 fps zu laufen, gibt es keinen Grund, die Tools zu umgehen, die Ihnen die Standardbibliothek zur Verfügung stellt.

Kylotan
quelle
10

Ich weiß, dass es sehr spät für die Party ist, aber Zeitänderungen und Antworten bleiben bestehen. C ++ 11 hat ziemlich umfassende Änderungen, von denen viele die Leistung von C ++ und der Standardbibliothek verbessern sollen. Es sieht so aus, als ob diejenigen, die STL oder Boost nicht verwenden, dazu neigen, auch nicht mit den neuen Standards Schritt zu halten, so dass den selbst gesponnenen Lösungen wichtige Verbesserungen fehlen, was natürlich nicht immer der Fall ist.

Ich habe STL für jedes Projekt von Mitte der 90er bis heute verwendet, mit Ausnahme einer kurzen Zeit bei EA. Ich denke, die Anti-STL-Seite hatte ein paar leicht rationale Gründe, es nicht zu benutzen. Die sind größtenteils weg. Benutzerdefinierte Zuweiser sind eine Lösung, die Verwendung von Reserve ist eine andere, und die Nichtübergabe von Dingen nach Wert ist eine dritte, aber diese sind recht einfach, und jeder Programmierer sollte diese kennen. Wichtiger ist jedoch die Verwendung von Algorithmen. Compiler-Autoren wissen genau, was for_each () tut, und können den Code optimieren. Das kann bei einer selbstgerollten Schleife nicht auftreten. for_each () für ein const-Objekt ist noch besser. Microsoft optimiert for_each in vielerlei Hinsicht, einschließlich der Serialisierung. Sie haben auch die AMP-Bibliothek, die parallel_for_each () hat. Wenn Sie eine Chance bekommen, sprechen Sie mit den Compiler-Ingenieuren darüber. Konsolen-Compiler werden optimieren, was verwendet wird. Ein kleines Problem mit Hühnchen und Eiern. Microsoft ist sehr stark mit C ++ 11 und die nächste XBox wird nicht anders sein. Ich habe keine Ahnung von PS4, wir haben noch keine bekommen.

Benutzerdefinierte Zuweisungen sind eine Möglichkeit, das Speicherproblem zu lösen. Eine andere (oft übersehene) Option ist die Verwendung von class based new und delete. Auf diese Weise können enorme Leistungssteigerungen erzielt werden.

Die Vorstellung, dass Boost und STL einen engen Blick auf die Lösung von Problemen haben, ist purer Wahnsinn. Ich bin verblüfft, wie viele Dinge in STL und Boost durch Eigenschaften und Richtlinien anpassbar sind. Suchen Sie nach case independent string compare als Beispiel.

In Bezug auf lange Verbindungszeiten und Code Bloat sollte das neue externe Template dabei helfen. Generell stelle ich fest, dass lange Kompilierzeiten durch übermäßige Kopplung und Missbrauch von pch entstehen.

Der überzeugendste Grund für die Verwendung von STL über homespun ist, dass Millionen von Menschen Ihnen bei der STL helfen können. Wie immer nicht vorzeitig optimieren und testen, testen, testen.

Tavison
quelle
interessante Ideen; Was meinst du mit " Klassenbasiertes Neu und Löschen "? Sie möchten einen Prozess beschleunigen, indem Sie Objekte verwenden, die sich bereits auf dem Haufen befinden?
Johnbakers
9

Dies ist ein heißes Thema in der Spieleentwicklung. Ich persönlich empfehle es nicht, außer vielleicht für EASTL wie oben erwähnt. Ich habe zwei Hauptprobleme mit STL (technisch gesehen "The C ++ Standard Library", da STL nicht mehr der Name ist) in Spielen. 1) Dynamische Speicherzuweisung verschwendet oft viel Zeit in Spielen, wenn STL verwendet wird. 2) Die Verwendung von STL fördert einen Array-of-Structs-Ansatz für die Spielarchitektur, wohingegen ein Array-of-Structs-Ansatz wesentlich cachefreundlicher ist.

Terrance Cohen
quelle
Wie bereits an anderer Stelle erwähnt, können Sie den Containerklassen benutzerdefinierte Zuordnungen zuweisen. Diese können auf Wunsch auch freie Listen verwenden (vorab zugewiesene Arrays). Das Array von Strukturen im Vergleich zu dem Array von Arrays hängt stark davon ab, was Sie versuchen - es gibt keine feste Regel, welches besser ist.
Skizz
Ich weiß Ihren Punkt zu schätzen, dass es wichtig ist, das Problem, das Sie lösen, gut zu verstehen. Aber mit Respekt denke ich immer noch, dass ich mit Ihrer Schlussfolgerung nicht einverstanden bin. Jedes Problem weist Verwendungsmuster auf, die nicht für benutzerdefinierte AWL-Zuweiser ausgedrückt werden können, die jedoch problemlos in einem benutzerdefinierten Container genutzt werden können, z. Das Anwenden einer festen Transformation auf ein Array homogener Typen führt sehr wahrscheinlich zu einer viel besseren Cache-Kohärenz als das Iterieren über einen Vektor polymorpher Typen und das Aufrufen virtueller Methoden.
Terrance Cohen
5

Es hängt davon ab, ob. Wie groß ist das Projekt, welche Plattform (en) und wie sieht der Zeitplan aus?

Wenn Sie an einem großen Projekt arbeiten, auf Plattformen mit begrenzten Ressourcen, einem beträchtlichen Zeitplan und einem beträchtlichen Budget, können Sie sich viel Ärger ersparen, indem Sie die unvermeidliche Hölle vermeiden, die eine halbe Million Zeilencodebasis erfordert Mit STL übersät, kann eine Framerate von über 30 nicht aufrechterhalten werden, es wird genug RAM verbraucht, um mehrere Assets aufzunehmen, und der Aufbau dauert 2 Stunden.

In anderen Situationen können STL und sogar Boost jedoch sehr nützlich sein, wenn sie richtig angewendet werden. Ich habe an Titeln mit einer Auswahl von STL / Boost gearbeitet, und es war ein absoluter Traum, sie zu codieren: Weniger Bugs / Leaks und einfach zu wartender Code bedeuten mehr Zeit für das Codieren neuer Funktionen! Gerade für Hobbyprojekte ist das ein Riesengewinn in der Motivationsabteilung.

Wissen, wann man Leistung gegen Bequemlichkeit eintauscht!

Jason Kozak
quelle
1
Msgstr "Wissen, wann Leistung gegen Bequemlichkeit getauscht werden muss". Ja. Dieser Satz allein ist eine ebenso gute Antwort wie jeder andere. Finden Sie heraus, was Sie mit Ihrem Spiel erreichen müssen, konsultieren Sie Kollegen und entscheiden Sie, ob STL Ihnen dabei hilft, dorthin zu gelangen oder Sie zu behindern. Ich würde sagen, wenn Sie nicht die Messlatte für Grafik und Leistung der nächsten Generation mit Ihrem Spiel setzen möchten, wird STL Ihnen wahrscheinlich helfen.
gkimsey
4

IMHO würde ich sagen, dass es gut passt, da STL bereits gut funktioniert und für die Aufgaben optimiert ist, für die es gemacht ist. Außerdem arbeitest du an einem Spiel, also benutze die Tools, die du zur Hand hast, um dein Leben zu erleichtern und deinen Code weniger anfällig für Fehler zu machen.

Warum sich die Mühe machen, das Rad neu zu erfinden, wenn Sie an etwas anderem wie der KI des Spiels, der Benutzererfahrung oder noch besser arbeiten können? Testen und Debuggen?

pctroll
quelle
2
In der Praxis ist die Leistung gegen Ende eines Projekts in der Regel ein kritisches Problem. Wenn Sie STL verwenden, haben Sie nur sehr wenige Optimierungsmöglichkeiten, da Ihre spezifischen Anwendungen verwendet und diese auf allgemeine Weise gelöst werden. Das Lösen bestimmter Fälle auf bestimmte Weise (und ohne dynamische Speicherzuweisung) ist fast immer leistungsstärker.
Terrance Cohen
2
Wenn Sie jedoch keine dynamische Speicherzuweisung wünschen, sollten Sie die STL nicht verwenden. Das ist genau der Punkt. Ihr eigener Code wird nicht besser und könnte sicherlich noch schlimmer sein. Die Designentscheidung , die STL zu missbrauchen, ist hier das Problem, nicht die STL, ihre Fähigkeiten oder ihre Leistungsmerkmale. Sie greifen den falschen Teil des Problems an.
Ed Ropple
4

STL ist absolut in Ordnung für die Verwendung in Spielen, sofern Sie es gut verstehen. Unser Motor nutzt es ziemlich ausgiebig und es war noch nie ein Problem. Ich habe keine Erfahrung mit der Entwicklung von Konsolen, was eine völlig andere Geschichte sein mag, aber es wird auf allen PC-Plattformen (Windows / Mac / Linux) gut unterstützt.

Das Wichtigste ist, die Stärken und Schwächen der einzelnen Containertypen zu kennen und den richtigen Container für die von Ihnen ausgeführte Aufgabe auszuwählen.

Jason Morales
quelle
4

Mein früherer Arbeitgeber wechselte von einer Reihe robuster benutzerdefinierter Containerklassen zu STL. Die Build-Zeiten stiegen und die Fehlerbehebung ging zurück, beides ziemlich signifikant. Wenn wir von vorne angefangen hätten, hätte STL (vielleicht besser verwendet) wahrscheinlich Sinn ergeben, aber es war mir nie klar, dass wir durch den Umstieg auf STL irgendetwas erreicht haben, das es rechtfertigt, funktionierenden, schnellen und debuggbaren Code zu verwerfen.

Bei meinen persönlichen Projekten hängt es vom Projekt ab, ob STL passt oder nicht. Wenn ich eine datengesteuerte, speicher- und cachezugriffsoptimierte Arbeit im Stil von Mike Acton ausführen möchte, denke ich zumindest an das Rolling meiner eigenen benutzerdefinierten Datenstrukturen. Wenn ich einige Algorithmen oder das Gameplay als Prototyp entwickle und Leistung, Skalierbarkeit, Zielplattform usw. nicht wichtig sind, greife ich automatisch zu STL.

Tom Hudson
quelle
4

Meine 2 Cent dafür ist, dass die STL gut funktioniert. Ich habe eine 3D-Game-Engine (keine AAA-Qualität, aber fortgeschritten genug - skriptbasierte Entitätstypen, verzögerter Renderer, integrierte Bullet-Physik) für den PC entwickelt und muss noch feststellen, dass Container zum Hauptengpass werden. Falsche 3D-API-Nutzung und schlechte Algorithmen waren jedes Mal die besten Ziele (ermittelt durch Profilerstellung!), Wenn ich versucht habe, etwas mehr Leistung herauszufinden.

Branan
quelle
3

Ich habe Spiele mit STL erstellt und es gefällt mir, und es scheint eine gute Leistung zu bringen.

Kevin Laity
quelle
3

Gute Frage! Eine spezifischere Frage ist, welche allgemeinen Anforderungen ein Spiel haben würde, die mit STL und Boost nicht erfüllt werden können.

Aufgrund der engen Speicherbeschränkungen der Konsolenhardware ist meiner Erfahrung nach jede Art von Container mit dynamischer Größe eine schlechte Idee, unabhängig davon, wie clever Ihr benutzerdefinierter Allokator ist. Container, die keine absichtlichen Grenzen haben, ermutigen Programmierer, Code zu schreiben, der die Grenzen ihrer Datensätze nicht einschränkt. Abhängig von unzähligen Variablen, die schwer zu verfolgen sind, können Sie Ihre Speicherbeschränkungen überschreiten. Ich habe die Vermutung, dass dies eine der Hauptursachen für Instabilität in modernen Spielen ist.

Darüber hinaus kann die übermäßige Verwendung von Vorlagen zu sehr langen Kompilierzeiten in einer großen Codebasis führen und die Größe Ihrer ausführbaren Datei aufblähen, sodass sie nicht mehr in den Cache eines Hilfskerns auf einem ps3 passt.

Für die reine PC-Entwicklung finde ich STL und Boost jedoch sehr gut. Während allgemeine Lösungen nicht immer ideal sind, sind sie oft gut genug. Ihre erste Lösung für ein Problem ist so gut wie nie ideal, und Sie verbessern oder ersetzen die Unzulänglichkeiten, bis sie gut genug sind.

Evan Rogers
quelle
2

Die STL passt gut zu Ihrem Spiel, wenn die STL gut zu Ihrem Spiel passt.

Wie bei allen Technologieentscheidungen, die während der Entwicklung getroffen wurden, müssen Sie die Vor- und Nachteile abwägen. Kann ich durch das Rollen meiner eigenen Bibliothek mehr Speicherplatz, Leistung und Produktivität nutzen, als wenn ich nur die STL verwende? Möglicherweise; Es ist jedoch genauso einfach, eine vectorImplementierung zu erstellen , die mehr Speicher benötigt, langsamer ist und einen hohen Wartungsaufwand erfordert, um die Funktion im Vergleich zu den bereits vorhandenen Funktionen aufrechtzuerhalten.

Leute sollten es nicht vermeiden, die STL in ihren Spielen zu verwenden, weil andere Leute es vermeiden, die STL in Spielen zu verwenden; Sie sollten es vermeiden, wenn sie alle ihre Optionen abgewogen haben und aufrichtig glauben, dass eine andere Implementierung die Qualität ihres Produkts verbessern wird.

Blair Holloway
quelle
2
Ich stimme dem letzten Teil Ihres Kommentars zu 100% zu, aber ich würde noch weiter gehen: Wenn Sie eindeutig nachweisen können, warum die STL keine gute Option ist, verwenden Sie die STL nicht. Ansonsten mache. Der Frachtkult (alles von "Oh, Spieleentwickler verwenden C ++!" Bis "Oh, Spieleentwickler verwenden keine STL!") Ist ungesund. Ich würde mich jedoch ein wenig mit Ihrem zweiten Absatz befassen: Es ist ziemlich unwahrscheinlich, dass Leute, die noch naiv genug sind, um zu glauben, eine Neuimplementierung der STL sei eine gute Idee, eine bessere vectorals die STL-Leute aufzubauen . Wenn Sie es schaffen, denken Sie nicht mehr, dass Sie es brauchen! :-)
Ed Ropple
2

Wie bei den meisten Fragen lautet die Antwort niemals "ja oder nein", schwarz oder weiß. STL ist eine gute Lösung für einige Probleme. Es sollte in Ordnung sein, STL für diese Probleme zu verwenden. Es ist ein Fehler anzunehmen, dass es nutzlos ist, aber es ist auch ein Fehler anzunehmen, dass es in jeder Situation angebracht ist, es zu verwenden.

Das größte Problem bei der Verwendung von STL in der Spieleentwicklung ist die Speicherzuweisung. Die Standard-Allokatoren von STL passen anscheinend nicht gut zu den bevorzugten Allokationsstrategien für die Spieleentwicklung. Natürlich können benutzerdefinierte Zuweiser verwendet werden, aber dies macht die ganze Idee weniger ansprechend, wenn Sie überlegen, ob Sie eine STL zu einer Nicht-STL-Codebasis hinzufügen möchten.

Wenn es sich bei Ihrer Codebasis um eine Nicht-STL-Codebasis handelt, ist möglicherweise niemand mit STL- oder Vorlagenkonzepten vertraut, um die benutzerdefinierten Zuweiser korrekt zu implementieren.

Dan Olson
quelle
2

Ich denke, diese Diskussion kann wie folgt zusammengefasst werden:

mittelmäßig geschriebener anwendungsspezifischer Code <gut geschriebener Universalcode <gut geschriebener anwendungsspezifischer Code

Jeder, dessen hausgemachte Lösung in die Kategorie 3 fallen würde, kennt mit Sicherheit die Antwort auf die ursprüngliche Frage für sein spezielles Problem. Die STL fällt in Kategorie 2. Für jemanden, der die Frage "Soll ich die STL verwenden" stellen muss, lautet die Antwort wahrscheinlich "Ja".


quelle
2

STL ist in Ordnung für die Verwendung auf einem PC, da sein fortschrittliches virtuelles Speichersystem die Notwendigkeit einer sorgfältigen Speicherzuweisung etwas weniger kritisch macht (obwohl man immer noch sehr vorsichtig sein muss). Auf einer Konsole mit begrenzten oder keinen virtuellen Speicherkapazitäten und exorbitanten Cache-Fehlerkosten sollten Sie keine benutzerdefinierten Datenstrukturen mit vorhersehbaren und / oder begrenzten Speicherzuordnungsmustern schreiben. (Und Sie werden mit Sicherheit nicht viel falsch machen, wenn Sie dasselbe bei einem PC-Spielprojekt tun.)

Mustafa Ekici
quelle
1

Ich denke, diese Frage ist wirklich eine größere, nicht gestellte Frage - sollte ich X in meinem Y verwenden ? Und die einzige Möglichkeit, dies wirklich zu beantworten, besteht darin, es selbst zu versuchen. Für jede Person, die sagt, dass X großartig funktioniert, gibt es jemanden, der sagt, dass es schrecklich ist. Und beide haben Recht - für ihr Projekt.

Das Tolle an Software ist, dass Sie im Gegensatz zu den meisten anderen Disziplinen die Dinge später immer wieder ändern können, wenn Sie feststellen, dass sie nicht so funktionieren, wie Sie es möchten. Finden Sie später heraus, dass STL in diesem Projekt nicht für Sie funktioniert? Reiß es raus, leg etwas anderes an seinen Platz. Gefällt es Ihnen nicht, wie Sie die Aufgaben auf Ihre Objekte aufgeteilt haben? Refactor. Gefällt es dir nicht, dass du Gegenstände benutzt hast? Ersetzen Sie sie durch gerade C-Methoden. Magst du es nicht, wenn alles in Strukturen und Methoden gespeichert ist, um sie zu manipulieren? Ersetzen Sie sie durch C ++ - Objekte.

Dennis Munsie
quelle
1
Auch wenn Sie Recht haben, kann das Umgestalten eine enorme Strafe bedeuten. Wenn Sie also eine fundierte und keine willkürliche Entscheidung treffen, sparen Sie auf lange Sicht Zeit.
Alan
1

Ich sage nein zur STL. Mein Grund ist ganz einfach:

  1. Sie brauchen die STL nicht, um Spiele zu schreiben. Nicht einmal große.
  2. STL erhöht die Kompilierzeit erheblich.
  3. Eine lange Kompilierungszeit führt zu weniger Iterationen in Ihrer Entwicklung.

Ich halte die Anzahl der Iterationen für äußerst wichtig, daher halte ich mich von der STL und anderen Entwicklungstechniken fern, die die Iterationen verlangsamen (z. B. Architekturen oder zu kompilierende Skriptsprachen).

Kostspielige Iterationen führen dazu, dass riesige Entwicklerteams versuchen, Dinge zu erledigen, bei denen nur sehr wenig passiert. Ich habe es gesehen und gehört, und einer der Schuldigen scheint die Kompilierungszeit für Vorlagenbibliotheken zu sein.

Richard Fabian
quelle
1
Ich bin mit den Kompilierzeiten einverstanden. Jede signifikante Kompilierungszeit verdoppelt die Menge der verlorenen Arbeit. ZB wenn die Kompilierung 5 Minuten dauert, werden Sie jedes Mal 10 Minuten mit Kaffee verbringen. ;)
Ipsquiggle
Obwohl ich beide Seiten dieses Arguments sehe, muss ich sagen, dass ich Ihrem Argument voll und ganz zustimme, Richard. +1.
Ingenieur