spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Lindraupe«

Ich glaube nicht, dass die einzelnen Level files größer als 100 MB werden, und wenns ein bisschen länger lädt wird es das Spiel auch verkraften ;)

Es ist eben nicht "ein bisschen" sondern liegt im Bereich von 10-100 mal langsamer. Fuer ein config File mit ein paar kb, kein Problem. Aber wenn man in Groessen von 100 MB vorstoesst, dann werden diese Unterschiede relevant. Erstmal sind 100 MB Nutzdaten in xml mal schnell 500. Dann muss beim Laden eine Menge zwischengespeichert werden, weil nicht alles direkt in die richtige Datenstruktur kopiert werden kann. Als Beispiel eine Karte mit 256 x 256 Feldern, fuer jedes Feld wird eine struct mit 10 Membern gespeichert. Wenn die Member ein paar ints und bools sind, reden wir hier von etwa 2MB Daten. Im xml wird für jeden Member z.B. ein Tag aufgemacht und wieder zugemacht, und dann steht die Zahl in ASCII oder sowas wie true/false. Das wird beim Laden dann wahrscheinlich in eine extra Struktur (XMLNode oder sowas) kopiert, in der dann wieder 2 dynamische Strings angelegt werden fuer den Namen des Tags und den Inhalt, dann passiert ein Stringvergleich und danach die Umwandlung in den int/bool. Dann wird die Struktur plus die Strings darin wieder freigegen. Wenn das nur 0,1 ms dauert, dann bist du nach 256x256x10 Werten schon bei mehreren Sekunden.

TGGC geht auf das ein was dot geschrieben hat.

Zitat von »Lindraupe«

Aber ich glaub ich werds trotzdem mal ausprobieren und schauen was rauskommt

So ist es. Erst machen. Dann optimieren, sofern im Release-Build notwendig.

Genau was TGGC sagt. Und meiner Erfahrung nach ist nicht nur die Datenmenge an sich, sondern insbesondere auch das Parsen der Textdaten nicht zu unterschätzen (wenn in der Textdatei float Werte stehen, muss aus denen ja erstmal ein float gebaut werden). Ich hab in praktisch jedem Projekt ein Converter-Tool, das mir Inputdaten erstmal in ein projektspezifisches binary Format konvertiert. Nachdem hier ja schon wieder die Premature-Optimization-Keule geschwungen wurde, möchte ich drauf hinweisen, dass es schon einen gewaltigen Unterschied macht, ob ich beim Debuggen jedes Mal erst 1 min warten muss oder nicht (zumindest mir wird das in jedem Projekt so schnell viel zu blöd, als dass ich nicht die 20 min investieren könnte um eine ordentliche Lösung zu bauen). Dabei muss es auch gar kein kompletter Level sein, selbst einfache Modelle reichen schon. Ich hatte schon Situationen wo ein größeres .obj File gestoppte 12 Minuten zum Laden brauchte. Die selbe Datei konvertiert in custom Binary lädt in Bruchteilen einer Sekunde (ja, der Unterschied kann wirklich so krass sein; das sind tatsächlich Zahlen aus der Praxis). Und dabei ist .obj noch extrem effizient im Vergleich zu XML...

(XML würde ich persönlich ja meiden wie die Pest, nicht nur weil es extrem ineffizient ist, sondern vor allem weil es rein als Format schon eine Fehlkonzeption ist, die ihresgleichen sucht. Ich frag mich ja oft, wie viele Gigawattstunden jeden Tag verschwendet werden, nur weil das ganze Internet auf so einem bescheuerten Format aufgebaut ist...)

Also wir haben auch reichlich komplexe Level-Dateien und länger als 3 Sekunden lädt davon aktuell keine selbst im Debug-Build. Ich sehe auch gar kein Problem erstmal mit XML anzufangen. Wie gesagt kann man das ja auch später umbauen, wenn es kein gangbarer Weg ist. Ich weiß nicht, warum man jetzt versuchen muss auf Teufel komm raus ein Binärformat zu empfehlen. Klar ist XML Bloat. Dafür kann man's halt prima lesen und von Hand ändern. Das geht mit Binärdateien eben nicht.

Was man auch beachten sollte ist dass es sich hier wohl eher um einen Anfänger als um einen Profientwickler handelt. Man kann so oft so viele schöne Dinge optimieren und das hat auch was weiß ich nicht welche Vorteile. Man sollte aber vielleicht auch einfach mal zurück denken was einen selbst überfordert hat und mit welchen Problemen man selbst zu kämpfen hatte. Ich hatte nach auch nach 2 Jahren noch andere Dinge im Kopf als irgendwelche Optimierungen von irgendwelchen Formaten. Der Hinweis ist gut, ja, die Frage die sich aber stellt ist in wie fern der TE überhaupt einschätzen kann was jetzt schnell und was langsam ist wenn er Code schreibt.

Also wenn mich jemand fragt ob es eine gute Idee ist seine 100 MB Daten in xml abzulegen, dann antworte ich halt mit: nein. Alles andere ist aus meiner Sicht gelogen. Klar weiss ein Anfaenger nicht was schnell und langsam ist, aber mit xml ist die Wahrscheinlichkeit eben wesentlich höher das er dann etwas unerträglich langsames baut. Darum sage ich so jemanden halt, das xml vergleichsweise langsam ist. Sonst hat er nach meiner Antwort noch weniger Ahnung. Klar gibts Leute die ihren komplexen Level in 3s laden, die haben dann aber vlt. doch nicht einen so komplexen Level oder wissen wie sie den optimiert in xml ablegen muessen.

Leute, jetzt mal ernsthaft. Er wird doch wohl kaum 100MB Daten haben bei seinem Level.

Unsere pre-optimization-Götter würden natürlich gern von an Anfang an Cache-freundliche DoD-Strukturen als bin-blob laden, damit ja kein Maschinenbefehl verschwendet wird oder cache misses entstehen

XML ist doch ok, das lädt ja nun wirklich selbst bei größeren Dateien in mehreren MByte-Bereichen ausreichend schnell. Der Vorteil, dass man es einfacher bearbeiten kann und man viel schneller Fehler beim Laden findet, ist ja nun mehr als genügend Argument für einen Anfänger und auch für kleinere bis mittlere Spiele. Man kann dann doch immer noch nach binär konvertieren und einen separaten Loader bauen