Entstehung und Erklärungen zum Skript-Benchmark
Dieser Thread ist ein Ableger eines großen Anno 1800 Benchmarks, der aufgeteilt werden musste.Der Hauptthread mit den Inhaltsverzeichnis bietet Erläuterungen die vorher gelesen werden sollten.
Wie bereits in der Motivation geschrieben wurde, kommt es für Anno 1800 zu einer Vielzahl an Problemen, sobald man versucht das Spiel sinnvoll zu Benchmarken:
Liste mit Problemen fürs Benchmarken
| Es gibt einem starken Leistungsabfall der durch aktives Spielen entsteht. Um so mehr der Spieler dabei von der Welt und den Menüs zu Gesicht bekommt, um so mehr System-RAM wird reserviert und um so stärker sinken FPS und 0,1% low Frametimes. |
| Die FPS die man am Anfang eines Endlosspiels erlebt unterscheiden sich massiv von dem Spielerlebnis im Lategame und insbesondere mit vielen benutzten DLCs |
| Kamerasprünge sind Teil des Gameplays aber sehr schlecht zu reproduzieren und dazu kommen noch zufällige Frametimepeaks, die immer wieder an unterschiedlichen Stellen auftauchen. |
| Sich verspätet aktualisierende Texturen stören die Optik und erscheinen vor allem mit langsameren CPUs sehr spät. |
| Die Einblendung von NPC-Portraits senkt die FPS deutlich und solche Einblendungen passieren oft zufällig. Direkt nach dem Start kostet es eher 5% der FPS, aber später können es 20-25% sein. |
| Feuer, Krankheit, Explosionen, Aufstände, Piraten und Co sind weitere zufällige Komponenten. |
| Kamerafahrten die von Rucklern gestört wurden enden an anderen Stellen. |
Hier sieht man z.B. den massiven Einfluss der verwendeten Hardware auf die Bildqualität durch verzögertes Aktualisieren der Texturen:
Meine Vorbereitungsphase(Abkürzung: VB) des Benchmarkskriptes
Leider dauert diese Phase ca. 33 Minuten.
Einfach so lange nur das Startbild anzugucken erhöht die RAM-Belegung in dieser Zeit nur um ca. 760MB.
Die Vorbereitungsphase schafft je nach CPU ca. 14500-15300MB.
Erst danach startet die erste eigentliche Messung.
Die geskriptete Benchmarkmessung
Im Vorfeld wurde eine lange Aufnahme des normalen Anno Spielens analysiert und darauf aufbauend die Gewichtung der Spielwelten und möglichst das Verhältnis aus nah, fern und mittelnaher Kameraposition übernommen.
Hier sieht man wie lange die Übergänge zwischen den Welten dauern können:
Und hier habe ich die Y-Achse anders skaliert um den Frametimeverlauf besser zeigen zu können.
Wie man sieht sind die FPS(inverse Frametimes) keineswegs einheitlich und schwanken stark in Abhängigkeit von der gezeigten Szene.
Wo manche Bereiche wie die Kontinentalinsel im Kap Trelawney die FPS mit dem Ryzen 1400 auf 12 FPS sinken lassen schafft die CPU an anderer Stelle durchaus 50 FPS.
Es sind also vor allem die unterschiedlichen Drawcalls die die FPS einbrechen lassen und die Simulation der globalen Wirtschaft hat nur einen kleineren Anteil.
Die Benchmarkphase beinhaltet Sprünge zwischen allen 5 Welten, sowie Sprünge und Standbilder in verschiedenen Situationen und Blickwinkeln.
Die Kamera wird um eine Flotte aus diversen Schiffstypen gedreht und über der Arktis wo der Expeditionsschrott gefunden werden kann.
Es werden eine Reihe Baumschulen gebaut und wieder abgerissen.
Es werden einige Menüs geöffnet, darunter auch das Expeditionsmenü und es werden verschiedene Gebäude angeklickt.
Auch springt die Kamera zwischen Kontoren/Inseln und sollte damit alles abdecken, das kritisch für die Leistung ist.
Insgesamt dauert jede der 5 Messungen über 11 Minuten und liefert daher gute Mittelwerte für FPS und vor allem für die Frametimes.
Sequenz zwischen den Messungen
Nach jeder Benchmarkphase gibt es eine Zwischensequenz(Abkürzung: ZS) die dazu da ist den RAM und VRAM neu zu durchmischen, sowie explodierte Gebäude aufzubauen.
Eine zweite identische Messung direkt anzuhängen, würde das reale Verhalten beim Spielen nicht repräsentieren, da die Auslagerungsdatei nicht wieder benötigt wird.
Daher behandelt die ZS auch andere Bereiche des Spiels und bringt diese zurück in den RAM/VRAM.
Erst danach startet die nächste Benchmarkphase und wie im Bereich über die Reproduzierbarkeit behandelt, wechseln sich diese beiden ab, bis 5 Messungen gemacht wurden.
Die Gesamtdauer für eine Messung inklusive PC-Neustart, Programm-Starts, Ladevorgang, Skriptbenchmark und Abspeichern der Messungen dauert ca. 2h und dies beinhaltet noch keine Änderungen der Hardware oder der Einstellungen.
Was passiert ohne die Vorbereitungsphase oder die Zwischensequenzen?
Ganz oben liegt das von mir verwendete Vorgehen mit der 33 minütigen Vorbereitungsmessung und den 5 Benchmarkmessungen zwischen denen noch die Zwischensequenzen abgehaldelt werden.
Lässt man entweder die Zwischensequenz oder die Vorbereitungsphase weg, steigen die FPS deutlich an(ca 30%) und sie werden auch schlechter reproduzierbar. Auch die Frametimes steigen um 10-15% an und der Effekt wäre noch deutlich größer wenn 16 GB anstelle von 64 GB Ram verwendet werden würden.
Neugestartet - keine Vorbereitung ist ein Beispiel wo zwar fünf Skript-Messungen ausgewertet wurden aber es wurde immer nur eine Benchmarkszene ohne eine Vorbereitungsmessung gemessen und dazwischen wurde das Spiel neu gestartet.
Die FPS sind hier nochmal besser und immerhin besser reproduzierbar.
Wie schon die Messungen ohne VB oder ZS zeigt sich ein falsches Bild der Lategame-Spielererfahrung.
Das Standbild mit dem der Spielstand geladen wird und mit dem auch die Skriptbenchmark-Messung startet vermittelt viel zu gute Frametime Werte, da es keine Kamerasprünge gibt und auch die FPS schwanken ziemlich stark, da es ab und zu zufällige NPC Meldungen gibt, die die FPS deutlich absenken. Für ein realistisches Bild ist so ein Benchmark also trotz des gleichen Spielstandes unbrauchbar.
Der Skriptbenchmark inklusive der Vorbereitung und der Zwischensequenzen bedeutet einen massiver Zeitaufwand, der jedoch seine Gründe hat, wie dieser Artikel euch hoffentlich vermitteln konnte.
<- Vorheriger Thread(Inhaltsverzeichnis, Einleitung) --Übersicht--nächster Thread(andere Benchmarks und Reproduziebarkeit) ->
Zuletzt bearbeitet:
