- Registriert
- Apr. 2008
- Beiträge
- 12.519
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Hinweis: Als ich die Testszenen herausgesucht und den Text geschrieben habe, hatte ich noch nicht die Vega64 und war auf meine GTX 680 2GB beschränkt. Wo Vega erwähnt wird, habe ich das nachträglich ergänzt.
Ein wichtiger Schritt zu guten Spieletests ist die Auswahl von Testsequenzen.
Als generellen Anspruch an diese würde ich folgende Punkte formulieren:
-Reproduzierbarkeit
-möglichst repräsentativ für das Gameplay.
-Fokus auf besonders anspruchsvolle Bereiche des Spiels
-Relevanz für den Leser
-Machbarkeit für den Tester
-Faire Auswahl an Spielen, die keinen Hersteller bevorzugt/benachteiligt
In der Realität wird jede Entscheidung nur ein Kompromiss aus diesen Punkten darstellen können und die Gewichtung ist höchst subjektiv. Mehr als Bemühen und ab und zu Reevaluierungen kann man nicht erwarten.
Für meine eigenen Test musste ich mir Spiele und Testszenen suchen, diese austesten und bewerten.
Mit einigen bin ich zufrieden, mit anderen weniger und einige sind wissentlich schlecht gewählt.
Ich möchte erstmal die oben aufgestellten Punkte genauer erläutern und dann meine Testszenen vorstellen und bewerten.
Punkt 1: Reproduzierbarkeit
Fokus auf besonders anspruchsvolle Bereiche des Spiels
Relevanz für den Leser
Machbarkeit für den Tester
Faire Auswahl an Spielen, die keinen Hersteller bevorzugt/benachteiligt
Mein Fazit: Viel Testen vor dem eigentlichen Testen sollte Pflicht sein.
Tools wie das OSD von MSI Afterburner+Rivatuner helfen beim herumprobieren die Auslastungen im Blick zu halten. Die neue Version erlaubt auch einen Frametimegraph(und andere Graphen) mit einzublenden und ein Blick auf die Lastverteilung über die CPU-Threads, macht sich auch nicht schlecht um zu sehen ob das Spiel eventuell HT/SMT nicht richtig erkennt oder einzelne Kerne übermäßig belastet.
Testmessungen helfen die Reproduzierbarkeit zu optimieren und zwischendurch sollte man innehalten um die Relevanz und Fairness zu überdenken.
Hier kommen meinen alten Testszenen mit Erläuterungen.
Sie halten sich nicht unbedingt an meine eigenen Ansprüche sondern sind eher aus den gegebenen Möglichkeiten heraus entstanden und teilweise zum austesten absichtlich schlecht gewählt. Aber als Beispiele durchaus gut zu gebrauchen.
Edit: Hier habe ich noch die GTX 680 genutzt und inzwischen sehe ich einige Dinge anders!
Daher werde ich nach und nach die neuen Testszenen einbringen, lasse die alten aber noch im Spoiler versteckt da.
Ich werde die neuen Testszenen nach und nach einfügen und würde mich über Fragen und Anregungen, sowie konstruktive Kritik freuen
.
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Hinweis: Als ich die Testszenen herausgesucht und den Text geschrieben habe, hatte ich noch nicht die Vega64 und war auf meine GTX 680 2GB beschränkt. Wo Vega erwähnt wird, habe ich das nachträglich ergänzt.
Ein wichtiger Schritt zu guten Spieletests ist die Auswahl von Testsequenzen.
Als generellen Anspruch an diese würde ich folgende Punkte formulieren:
-Reproduzierbarkeit
-möglichst repräsentativ für das Gameplay.
-Fokus auf besonders anspruchsvolle Bereiche des Spiels
-Relevanz für den Leser
-Machbarkeit für den Tester
-Faire Auswahl an Spielen, die keinen Hersteller bevorzugt/benachteiligt
In der Realität wird jede Entscheidung nur ein Kompromiss aus diesen Punkten darstellen können und die Gewichtung ist höchst subjektiv. Mehr als Bemühen und ab und zu Reevaluierungen kann man nicht erwarten.
Für meine eigenen Test musste ich mir Spiele und Testszenen suchen, diese austesten und bewerten.
Mit einigen bin ich zufrieden, mit anderen weniger und einige sind wissentlich schlecht gewählt.
Ich möchte erstmal die oben aufgestellten Punkte genauer erläutern und dann meine Testszenen vorstellen und bewerten.
Punkt 1: Reproduzierbarkeit
Hier besteht ein Konflikt mit den Punkten Machbarkeit und repräsentativem Gameplay.
Gut wäre es dutzende Male über eine mehrere Minuten dauernde Spielszene zu testen. Machbar ist das nicht, da dann jeder Test extrem lange dauert und der Aufwand zu groß ist.
Integrierte Benchmarks oder andere Szenen, die keinen Input des Testers benötigen kann man eher lange laufen lassen, solange der Tester ein gutes Buch oder einen zweiten PC zur Hand hat...aber auch das geht nicht wenn die Zeit drängt wegen einer bevorstehenden Deadline.
Es gilt also bei der Auswahl, den Zeitaufwand trotz ausreichender Reproduzierbarkeit zu optimieren.
Echtes Gameplay ist in der Regel schwerer zu reproduzieren als integrierte Benchmarks.
Vor allem Spielerinput stellt hohe Anforderungen an die Konsistenz des Testers und Multiplayer-Spiele sind noch kritischer.
Manche Szenen erweisen sich daher als ungeeignet.
Ein paar kann man durch längere Sequenzen oder klareren Ablauf "retten". So habe ich in RomeTW eine super reproduzierbare Intro-Szene, die aber nicht dem Gameplay entspricht und eine Kampfszene, die stark von der Kameraposition und dem Kampfverlauf abhängt. "Gerettet" habe ich die Kampfszene, indem ich sie ab Start, so lang gewählt habe, dass ein guter Teil Kampf enthalten ist, aber so kurz, dass das Schlachtenglück nicht zu stark variiert. Auch justiere ich nicht mehr die Kamera selbst, sondern lasse sie automatisch nachrücken. Perfekt reproduzierbar wird es damit immer noch nicht, aber gut genug für meine Zwecke.
Auch integrierte Benchmarks sind nicht immer brauchbar. So ist z.B. der Benchmark von Mafia 2 starken Schwankungen unterlegen und ein absichtlich schlechtes Beispiel.
Die Anzahl der Wiederholungen ist ebenfalls wichtig.
Ich hatte mich erst für 4 bis 5 Messungen entschieden, von denen ich über drei Messungen mittle. Dabei habe ich jedes Mal die erste Messung verworfen, da diese, in einigen Spielen, von Nachladerucklern geprägt ist. Beispiel Starcraft 2:
Wie man im ersten Bild sieht, gibt es in der ersten Messung zwei große Ausreißer und weitere kleinere, die in der zweiten Messung nicht auftauchen. Die nächsten zwei Vergleiche von Messung 2 mit Messung 3 bzw. 4 sind dagegen reproduzierbar. Ich versuche noch eine 5. Messung zu machen um eine in Reserve zu haben, falls ich bei der Auswertung feststelle, dass einer der Messungen 2-4 aus der Reihe tanzt. Das passiert ab und zu, wenn Windows sich entscheidet "Irgendwas" Rödeln zu müssen oder nach updates sucht oder der Windows Defender Spaß daran hat die Messung zu stören....usw.
Auch in Spielen, die mit der ersten Messung keine Probleme haben fand ich es sinnvoll die erste Messung, die ich "Vormessung" nenne durchzuführen. So kommt man nochmal in die Verlegenheit den genauen Ablauf durchzuspielen und ist bei den eigentlichen Messungen konsistenter. Ab jetzt werde ich die Vormessung weitestgehend ignorieren und die ausgewerteten Messungen als Messung 1-3 bezeichnen, auch wenn sie eigentlich Messung 2-4 heißen müssten.
Noch besser als über drei Messungen zu mitteln wäre es sicherlich 5 Messungen zu mitteln. Dafür fehlte mir aber die Zeit und Lust
.
Interessanterweise sind in einigen Vormessungen die avg FPS besser als in den nachfolgenden Messungen obwohl es starke Ausreißer gibt. Die P99.9 Werte sind damit zwar schlechter aber teils sind sogar die P99 Werte besser.
Dann gilt es herauszufinden ob die Performance driftet oder ob Neuladen zu sowas wie Nachladerucker-light führt.
In meiner The Witcher 3-Novigrad-Szene konnte ich deutlich vermehrte Probleme bei der Vormessung, also direkt nach Start des Spiels und erstem laden des savegames, feststellen. Aber auch nach Ablaufen eines Tests und anschließendem Neuladen des savegames für die nächste Messung konnte ich vermehrte Schwankungen feststellen, die nicht auftraten, wenn ich zum Ausgangspunkt zurückgelaufen bin.
Daher habe ich meine Testszene, von einem Lauf von A nach B mit neuladen zum Punkt A, durch einen Rundgang von A nach A und starten der nächsten Messung ohne Ladeunterbrechung, ersetzt.
Dabei muss der Rundgang groß genug ausgelegt sein, sonst werden die herumstehenden/laufenden NPCs nicht für die nächste Messung durch andere ersetzt und man hätte einen systematischen Fehler in der Messung.
In City Skylines ist wiederum Neuladen wichtig, weil sich im Laufe der Zeit das Stadtbild verändert. Häuser kommen dazu oder Stau auf den Straßen verändert sich. Neuladen zwischen den Messungen sorgt für gleiche Ausgangssituationen.
Problematisch sind immer Spiele mit unregelmäßigen Ausreißern in den Frametimes. Einerseits sind diese interessant, weil sich eventuelle Hardware- oder Softwareprobleme zeigen. Andererseits muss die Testsequenz recht lang sein und öfter wiederholt werden, da die Reproduzierbarkeit nicht so gegeben ist wie bei der Betrachtung von avg FPS.
Gut wäre es dutzende Male über eine mehrere Minuten dauernde Spielszene zu testen. Machbar ist das nicht, da dann jeder Test extrem lange dauert und der Aufwand zu groß ist.
Integrierte Benchmarks oder andere Szenen, die keinen Input des Testers benötigen kann man eher lange laufen lassen, solange der Tester ein gutes Buch oder einen zweiten PC zur Hand hat...aber auch das geht nicht wenn die Zeit drängt wegen einer bevorstehenden Deadline.
Es gilt also bei der Auswahl, den Zeitaufwand trotz ausreichender Reproduzierbarkeit zu optimieren.
Echtes Gameplay ist in der Regel schwerer zu reproduzieren als integrierte Benchmarks.
Vor allem Spielerinput stellt hohe Anforderungen an die Konsistenz des Testers und Multiplayer-Spiele sind noch kritischer.
Manche Szenen erweisen sich daher als ungeeignet.
Ein paar kann man durch längere Sequenzen oder klareren Ablauf "retten". So habe ich in RomeTW eine super reproduzierbare Intro-Szene, die aber nicht dem Gameplay entspricht und eine Kampfszene, die stark von der Kameraposition und dem Kampfverlauf abhängt. "Gerettet" habe ich die Kampfszene, indem ich sie ab Start, so lang gewählt habe, dass ein guter Teil Kampf enthalten ist, aber so kurz, dass das Schlachtenglück nicht zu stark variiert. Auch justiere ich nicht mehr die Kamera selbst, sondern lasse sie automatisch nachrücken. Perfekt reproduzierbar wird es damit immer noch nicht, aber gut genug für meine Zwecke.
Auch integrierte Benchmarks sind nicht immer brauchbar. So ist z.B. der Benchmark von Mafia 2 starken Schwankungen unterlegen und ein absichtlich schlechtes Beispiel.
Die Anzahl der Wiederholungen ist ebenfalls wichtig.
Ich hatte mich erst für 4 bis 5 Messungen entschieden, von denen ich über drei Messungen mittle. Dabei habe ich jedes Mal die erste Messung verworfen, da diese, in einigen Spielen, von Nachladerucklern geprägt ist. Beispiel Starcraft 2:
Wie man im ersten Bild sieht, gibt es in der ersten Messung zwei große Ausreißer und weitere kleinere, die in der zweiten Messung nicht auftauchen. Die nächsten zwei Vergleiche von Messung 2 mit Messung 3 bzw. 4 sind dagegen reproduzierbar. Ich versuche noch eine 5. Messung zu machen um eine in Reserve zu haben, falls ich bei der Auswertung feststelle, dass einer der Messungen 2-4 aus der Reihe tanzt. Das passiert ab und zu, wenn Windows sich entscheidet "Irgendwas" Rödeln zu müssen oder nach updates sucht oder der Windows Defender Spaß daran hat die Messung zu stören....usw.
Auch in Spielen, die mit der ersten Messung keine Probleme haben fand ich es sinnvoll die erste Messung, die ich "Vormessung" nenne durchzuführen. So kommt man nochmal in die Verlegenheit den genauen Ablauf durchzuspielen und ist bei den eigentlichen Messungen konsistenter. Ab jetzt werde ich die Vormessung weitestgehend ignorieren und die ausgewerteten Messungen als Messung 1-3 bezeichnen, auch wenn sie eigentlich Messung 2-4 heißen müssten.
Noch besser als über drei Messungen zu mitteln wäre es sicherlich 5 Messungen zu mitteln. Dafür fehlte mir aber die Zeit und Lust
.Interessanterweise sind in einigen Vormessungen die avg FPS besser als in den nachfolgenden Messungen obwohl es starke Ausreißer gibt. Die P99.9 Werte sind damit zwar schlechter aber teils sind sogar die P99 Werte besser.
Dann gilt es herauszufinden ob die Performance driftet oder ob Neuladen zu sowas wie Nachladerucker-light führt.
In meiner The Witcher 3-Novigrad-Szene konnte ich deutlich vermehrte Probleme bei der Vormessung, also direkt nach Start des Spiels und erstem laden des savegames, feststellen. Aber auch nach Ablaufen eines Tests und anschließendem Neuladen des savegames für die nächste Messung konnte ich vermehrte Schwankungen feststellen, die nicht auftraten, wenn ich zum Ausgangspunkt zurückgelaufen bin.
Daher habe ich meine Testszene, von einem Lauf von A nach B mit neuladen zum Punkt A, durch einen Rundgang von A nach A und starten der nächsten Messung ohne Ladeunterbrechung, ersetzt.
Dabei muss der Rundgang groß genug ausgelegt sein, sonst werden die herumstehenden/laufenden NPCs nicht für die nächste Messung durch andere ersetzt und man hätte einen systematischen Fehler in der Messung.
In City Skylines ist wiederum Neuladen wichtig, weil sich im Laufe der Zeit das Stadtbild verändert. Häuser kommen dazu oder Stau auf den Straßen verändert sich. Neuladen zwischen den Messungen sorgt für gleiche Ausgangssituationen.
Problematisch sind immer Spiele mit unregelmäßigen Ausreißern in den Frametimes. Einerseits sind diese interessant, weil sich eventuelle Hardware- oder Softwareprobleme zeigen. Andererseits muss die Testsequenz recht lang sein und öfter wiederholt werden, da die Reproduzierbarkeit nicht so gegeben ist wie bei der Betrachtung von avg FPS.
Meinem Verständnis nach sollte die Auswahl auf möglichst anspruchsvollen Szenen fallen.
Szenen die auf jeder Hardware problemlos laufen sind unwichtig. Ein Aufbaustrategiespiel, das mit der kleine Siedlung am Anfang, auf jeder noch so alten CPU läuft, sollte man im Lategame testen.
Da wo das System ins Schwitzen kommt und sich Unterschiede zwischen "ruckelig" und "noch ganz OK" zeigen können. Es muss ja nicht die ultrahardcore Szene sein, die 99.9% der Spieler nie sehen werden oder die gar künstlich erzeugt wurde, aber wenn es normal zum Spiel gehört sollte man dort testen.
Wichtig ist herauszufinden warum die Szene so anspruchsvoll ist. Denn wenn es sich um eine GPU limitierte Szene handelt, wo die Leistung wegen den vielen Grafikeffekten/Tessalation/Sonstigem einbricht und nicht weil die CPU stärker belastet ist, kann man die Szene für einen CPU-Test ausschließen. Oder versuchen durch andere Grafikeinstellungen die Limitierung Richtung CPU zu verschieben. Umgekehrt gilt natürlich das gleiche für einen Grafikkartentest.
Wenn sich keine besonders anspruchsvolle Szene finden lässt, sollte man zumindest versuchen eine typische Belastung zu finden.
Szenen die auf jeder Hardware problemlos laufen sind unwichtig. Ein Aufbaustrategiespiel, das mit der kleine Siedlung am Anfang, auf jeder noch so alten CPU läuft, sollte man im Lategame testen.
Da wo das System ins Schwitzen kommt und sich Unterschiede zwischen "ruckelig" und "noch ganz OK" zeigen können. Es muss ja nicht die ultrahardcore Szene sein, die 99.9% der Spieler nie sehen werden oder die gar künstlich erzeugt wurde, aber wenn es normal zum Spiel gehört sollte man dort testen.
Wichtig ist herauszufinden warum die Szene so anspruchsvoll ist. Denn wenn es sich um eine GPU limitierte Szene handelt, wo die Leistung wegen den vielen Grafikeffekten/Tessalation/Sonstigem einbricht und nicht weil die CPU stärker belastet ist, kann man die Szene für einen CPU-Test ausschließen. Oder versuchen durch andere Grafikeinstellungen die Limitierung Richtung CPU zu verschieben. Umgekehrt gilt natürlich das gleiche für einen Grafikkartentest.
Wenn sich keine besonders anspruchsvolle Szene finden lässt, sollte man zumindest versuchen eine typische Belastung zu finden.
Problematisches Thema. Hier meine ich vor allem die Spieleauswahl und weniger die Szenen.
Sollte man ein AotS testen, weil es so schön multicore-CPUs auslastet? Denn scheinbar spielt es kaum jemand und das würde es irrelevant für die meisten Leser machen. Für einige Leser mag es aber relevant sein, weil es ein Ausblick sein könnte, wie künftige Echtzeitstrategiespiele laufen können.
Starcraft 2 ist hingegen ein Spiel das immer noch gespielt wird, das aber nur 2 (eventuell 3??) Kerne nutzt. Während das normale 1v1 problemlos läuft, brechen 4v4 oder Coop-missionen massiv ein und so manche Mutators Mission auf brutal verkommt zur Diashow.
Schuld ist ganz klar die massive Last auf einem Thread. Aber ist es nicht auch 2017 wichtig singlethread Leistung zu testen? Ich meine schon....so mancher wird anderer Ansicht sein.
Für mich war die Auswahl einfach....ich habe alles probiert was ich besitze....die Spiele ignoriert, die so anspruchslos laufen, das jede halbwegs aktuelle Hardware reicht und die, wo ich nicht wusste was ich testen soll.
Etwas problematisch ist auch meine Grafikkarte.
Nur wenige werden eine Vega64 haben aber zumindest bin ich jetzt nicht mehr so GPU limitiert wie mit meiner alten GTX680.
Auf der anderen Seite arbeiten auch nicht viele CPU Tests mit einer solchen und so fülle ich eventuell eine Nische.
Um auf die Spieleauswahl zurückzukommen:
Vom Prinzip her würde ich idealerweise eine bunte Mischung vorschlagen, am besten unterteilt in verschiedene Bereiche.
So dass am Ende nicht nur ein Gesamtergebnis da steht, sondern mehrere zusammengesetzte Ergebnisse für z.B. Spiele mit 1-3 Thread Unterstützung, eines für 4+ Unterstützung und dann noch nach Genre sortiert. Shooter und Rennspiele, Aufbaustrategie und RTS, Rollenspiele und Telltale......dafür braucht man aber sehr viele Spiele und da kommen wir wieder in Konflikt mit der Machbarkeit
.
. Hier meine ich vor allem die Spieleauswahl und weniger die Szenen. Sollte man ein AotS testen, weil es so schön multicore-CPUs auslastet? Denn scheinbar spielt es kaum jemand und das würde es irrelevant für die meisten Leser machen. Für einige Leser mag es aber relevant sein, weil es ein Ausblick sein könnte, wie künftige Echtzeitstrategiespiele laufen können.
Starcraft 2 ist hingegen ein Spiel das immer noch gespielt wird, das aber nur 2 (eventuell 3??) Kerne nutzt. Während das normale 1v1 problemlos läuft, brechen 4v4 oder Coop-missionen massiv ein und so manche Mutators Mission auf brutal verkommt zur Diashow.
Schuld ist ganz klar die massive Last auf einem Thread. Aber ist es nicht auch 2017 wichtig singlethread Leistung zu testen? Ich meine schon....so mancher wird anderer Ansicht sein.
Für mich war die Auswahl einfach....ich habe alles probiert was ich besitze....die Spiele ignoriert, die so anspruchslos laufen, das jede halbwegs aktuelle Hardware reicht und die, wo ich nicht wusste was ich testen soll.
Etwas problematisch ist auch meine Grafikkarte.
Nur wenige werden eine Vega64 haben aber zumindest bin ich jetzt nicht mehr so GPU limitiert wie mit meiner alten GTX680.
Auf der anderen Seite arbeiten auch nicht viele CPU Tests mit einer solchen und so fülle ich eventuell eine Nische
.Um auf die Spieleauswahl zurückzukommen:
Vom Prinzip her würde ich idealerweise eine bunte Mischung vorschlagen, am besten unterteilt in verschiedene Bereiche.
So dass am Ende nicht nur ein Gesamtergebnis da steht, sondern mehrere zusammengesetzte Ergebnisse für z.B. Spiele mit 1-3 Thread Unterstützung, eines für 4+ Unterstützung und dann noch nach Genre sortiert. Shooter und Rennspiele, Aufbaustrategie und RTS, Rollenspiele und Telltale......dafür braucht man aber sehr viele Spiele und da kommen wir wieder in Konflikt mit der Machbarkeit
.Darauf bin ich ja schon in den vorherigen Punkten eingegangen......es ist ein Zeitproblem. Und ein Personalproblem. Ich habe immer wieder zwischendurch getestet und es dauert einfach sehr lange wenn man es ausführlich und sorgfältig macht. In einer Redaktion mit mehreren Mitarbeitern kann es auch problematisch werden, wenn nicht genau definiert ist wie die Testszenen zu laufen haben und verschiedene Tester verschiedene Ergebnisse produzieren.
Es gibt sicherlich noch dutzende weiter Punkte. Aber ich möchte es hier dabei belassen.
Es gibt sicherlich noch dutzende weiter Punkte. Aber ich möchte es hier dabei belassen.
Noch problematischer als die Relevanz für den Leser .
Es ist klar, dass Spiele auf CPUs von AMD und Intel unterschiedlich laufen und das gilt noch mehr für Grafikkarten von AMD und Nvidia. Einiges davon ist den unterschiedlichen Architekturen geschuldet, Treiberunterschiede, Spieleoptimierung usw.
Das alles ist normal und DER Grund warum man überhaupt Tests macht und nicht nur Spezifikationen vergleicht. Jedoch wird teilweise unfair gespielt. Ich bin kein Programmierer, der beurteilen kann wo und wie geschummelt wird, aber ich habe einige Berichte gelesen und Videos geguckt, die mich dafür sensibilisiert haben, das unlauterer Wettbewerb vor allem für Intel und Nvidia dazugehört. AdoredTV hat dazu einige sehr gute Videos gemacht, die sowohl Intel als auch Nvidia anprangern....es ist natürlich stark einseitig und ich möchte hier keine Diskussion ob AMD irgendwo das gleiche macht oder nicht!
Aber prinzipiell ist es ein wichtiges Thema. Intel hat in der Vergangenheit z.B. den Chipzilla Compiler manipuliert um ihn nachgucken zu lassen auf welchem Prozessor der Code läuft. Wenn die Antwort "GenuineIntel" lautete wurde der bestmögliche Code gewählt, ansonsten der schlechtestmögliche. Quelle:https://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code-amd-via-chips
Einige Nvidia Gameworks unterstützte Spiele machen sich z.B. zu nutze, dass AMD Grafikkarten schlechter mit Tessellation klar kommen und setzen diese unnötig und übertrieben ein während gleichzeitig AMD der vollständige Code verwehrt bleibt und daher schlechter darauf optimieren kann...und wichtiger....einfach nicht so umfangreiche Tessellationsleistung in ihren Chips verbaut haben.
Das ändert natürlich nichts daran, das Leser von Tests trotzdem betroffene Spiele spielen wollen und es sie nicht interessiert warum die eine Hardware so Probleme hat. Trotzdem finde ich, man sollte als Tester im Bereich der Möglichkeiten unsinnige Einstellungen vermeiden. Wenn Tessellation 8x zu 64x auf AMD Karten fast doppelt so viel Leistung kostet wie auf Nvidia Karten ohne sichtbaren Qualitätsunterschied, dann sollte man bei 8x bleiben und in der Benchmarkbeschreibung darauf hinweisen das man es so gehandhabt hat.
Das gleiche gilt natürlich auch für AMD unterstützte Spiele, bei denen man ebenso hinschauen sollte ob man alle Slider einfach nach rechts knallt oder ob es Gründe dagegen gibt.
Aber eigentlich ging es hier nicht um die Einstellungen, sondern um die Spiele und Szenenauswahl.
Also dazu....Wenn man die Wahl hat zwischen Spielen mit eindeutigem Bias und ohne sollte man das durchaus in die Entscheidung mit einfließen lassen. Und auch innerhalb der Spiele mag es Szenen geben die das eine oder andere Lager bevorzugen.
Wenn eine Szene aus anderen Gründen besser scheint, dann ist das so, aber wenn es die Wahl gibt, sucht man eventuell besser nach einer dritten, die neutraler scheint.
Aber natürlich sollte man, in einem CPU-Test, nicht eine CPU intensive Szene vermeiden, weil sich hier die Unterschiede besser zeigen...denn das ist es ja wofür man testet.
Allerdings gab es gerade zum Launch von Ryzen offensichtlich verbuggte Performance in manchen Spielen. So wurden die 8 Kerne in AotS nicht wirklich genutzt und man war schlechter als so mancher 4 Kerner. Das wurde später gepatcht aber es wäre ein Beispiel, wo man solche Problemfälle zumindest nicht in ein Gesamtrating einfließen lassen sollte.
.Es ist klar, dass Spiele auf CPUs von AMD und Intel unterschiedlich laufen und das gilt noch mehr für Grafikkarten von AMD und Nvidia. Einiges davon ist den unterschiedlichen Architekturen geschuldet, Treiberunterschiede, Spieleoptimierung usw.
Das alles ist normal und DER Grund warum man überhaupt Tests macht und nicht nur Spezifikationen vergleicht. Jedoch wird teilweise unfair gespielt. Ich bin kein Programmierer, der beurteilen kann wo und wie geschummelt wird, aber ich habe einige Berichte gelesen und Videos geguckt, die mich dafür sensibilisiert haben, das unlauterer Wettbewerb vor allem für Intel und Nvidia dazugehört. AdoredTV hat dazu einige sehr gute Videos gemacht, die sowohl Intel als auch Nvidia anprangern....es ist natürlich stark einseitig und ich möchte hier keine Diskussion ob AMD irgendwo das gleiche macht oder nicht!
Aber prinzipiell ist es ein wichtiges Thema. Intel hat in der Vergangenheit z.B. den Chipzilla Compiler manipuliert um ihn nachgucken zu lassen auf welchem Prozessor der Code läuft. Wenn die Antwort "GenuineIntel" lautete wurde der bestmögliche Code gewählt, ansonsten der schlechtestmögliche. Quelle:https://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code-amd-via-chips
Einige Nvidia Gameworks unterstützte Spiele machen sich z.B. zu nutze, dass AMD Grafikkarten schlechter mit Tessellation klar kommen und setzen diese unnötig und übertrieben ein während gleichzeitig AMD der vollständige Code verwehrt bleibt und daher schlechter darauf optimieren kann...und wichtiger....einfach nicht so umfangreiche Tessellationsleistung in ihren Chips verbaut haben.
Das ändert natürlich nichts daran, das Leser von Tests trotzdem betroffene Spiele spielen wollen und es sie nicht interessiert warum die eine Hardware so Probleme hat. Trotzdem finde ich, man sollte als Tester im Bereich der Möglichkeiten unsinnige Einstellungen vermeiden. Wenn Tessellation 8x zu 64x auf AMD Karten fast doppelt so viel Leistung kostet wie auf Nvidia Karten ohne sichtbaren Qualitätsunterschied, dann sollte man bei 8x bleiben und in der Benchmarkbeschreibung darauf hinweisen das man es so gehandhabt hat.
Das gleiche gilt natürlich auch für AMD unterstützte Spiele, bei denen man ebenso hinschauen sollte ob man alle Slider einfach nach rechts knallt oder ob es Gründe dagegen gibt.
Aber eigentlich ging es hier nicht um die Einstellungen, sondern um die Spiele und Szenenauswahl
.Also dazu....Wenn man die Wahl hat zwischen Spielen mit eindeutigem Bias und ohne sollte man das durchaus in die Entscheidung mit einfließen lassen. Und auch innerhalb der Spiele mag es Szenen geben die das eine oder andere Lager bevorzugen.
Wenn eine Szene aus anderen Gründen besser scheint, dann ist das so, aber wenn es die Wahl gibt, sucht man eventuell besser nach einer dritten, die neutraler scheint.
Aber natürlich sollte man, in einem CPU-Test, nicht eine CPU intensive Szene vermeiden, weil sich hier die Unterschiede besser zeigen...denn das ist es ja wofür man testet
.Allerdings gab es gerade zum Launch von Ryzen offensichtlich verbuggte Performance in manchen Spielen. So wurden die 8 Kerne in AotS nicht wirklich genutzt und man war schlechter als so mancher 4 Kerner. Das wurde später gepatcht aber es wäre ein Beispiel, wo man solche Problemfälle zumindest nicht in ein Gesamtrating einfließen lassen sollte.
Mein Fazit: Viel Testen vor dem eigentlichen Testen sollte Pflicht sein.
Tools wie das OSD von MSI Afterburner+Rivatuner helfen beim herumprobieren die Auslastungen im Blick zu halten. Die neue Version erlaubt auch einen Frametimegraph(und andere Graphen) mit einzublenden und ein Blick auf die Lastverteilung über die CPU-Threads, macht sich auch nicht schlecht um zu sehen ob das Spiel eventuell HT/SMT nicht richtig erkennt oder einzelne Kerne übermäßig belastet.
Testmessungen helfen die Reproduzierbarkeit zu optimieren und zwischendurch sollte man innehalten um die Relevanz und Fairness zu überdenken.
Hier kommen meinen alten Testszenen mit Erläuterungen.
Sie halten sich nicht unbedingt an meine eigenen Ansprüche sondern sind eher aus den gegebenen Möglichkeiten heraus entstanden und teilweise zum austesten absichtlich schlecht gewählt. Aber als Beispiele durchaus gut zu gebrauchen.
Edit: Hier habe ich noch die GTX 680 genutzt und inzwischen sehe ich einige Dinge anders!
Daher werde ich nach und nach die neuen Testszenen einbringen, lasse die alten aber noch im Spoiler versteckt da.
Zu beachten ist, dass ich mit OBS und X264 aufgenommen habe. Die CPU Auslastung schließt also Spiel und Aufnahme mit ein.
-City Skylines
Heroes of the Storm
Mafia 2
Mafia 3 Demo
Prey
Prison Architect
Rise of the Tomb Raider
Rome Barbarian Invasion
Starcraft 2
The Devision
Thief
Tomb Raider(2013)
The Witcher 1
The Witcher 2
The Witcher 3
Das war es mit den dokumentierten Testszenen, die ich untersucht habe.
Ich hatte noch eine ganze Reihe Spiele mehr getestet, aber viele waren unzuverlässig, uninteressant, haben die CPU nicht belastet oder waren einfach zu viel Arbeit.
Hier ein paar Gedanken zu den verworfenen Tests:
Zufrieden bin ich bei meinen eigenen Testszenen nur mit Heroes of the Storm, Prison Archiect, Starcraft 2, und Witcher 3.
Mit Einschränkungen City Skylines, Mafia 3, Prey, RomeTW und Witcher1 und 2.
-City Skylines
https://www.youtube.com/watch?v=EHlsYIMzpjU&index=2&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Ich habe das Spiel im Sonderangebot bekommen und selbst kaum gespielt. Es scheint aber sehr gut zu sein und mit der hohen CPU Last und dem CPU Limit ein geeigneter Testkandidat. Da meine kleinen Städtchen zu klein zum testen waren, habe ich mir aus dem Steamworkshop ein savegame mit Namen "Atoll" heruntergeladen. Der Vorteil gegenüber anderen savegames war die große Stadt ohne Mods installieren zu müssen. Denn Mods haben bei meinen Tests die Leistung stark verschlechtert und sind wieder runter geflogen.
Ein Fehler meinerseits ist der überlaufende VRam. Die 2GB sind dauerhaft voll und sowas sollte man vermeiden. Texturen auf low anstatt high bringen VRAm auf 1500MB runter aber nur 2 FPS mehr und die Frametimes bleiben auch ähnlich.
Gerne hätte ich eine niedrigere Kamerafahrt gemacht, ein neues Gebiet hochgezogen oder ähnliches. Leider ließ die Reproduzierbarkeit dies nicht zu. Deshalb die starre Kameraposition mittig über der Stadt. Die 40s fangen eine gute Auswahl an kleinen Ausreißern ein und für jede Messung lade ich das savegame neu. Da sich das Stadtbild leicht verändert messe ich nicht direkt hintereinander sondern nehme die Ladezeiten in Kauf um zuverlässig die gleiche Situation zu messen.
Insgesamt bin ich mit dem Test ganz zufrieden. Es ist reproduzierbar, zeigt signifikante Unterschiede für anderen CPU-Takt, RAM-Takt oder den Wechsel von 8 auf 4 Kerne, sowie durch ausschalten von SMT.
Ich habe das Spiel im Sonderangebot bekommen und selbst kaum gespielt. Es scheint aber sehr gut zu sein und mit der hohen CPU Last und dem CPU Limit ein geeigneter Testkandidat. Da meine kleinen Städtchen zu klein zum testen waren, habe ich mir aus dem Steamworkshop ein savegame mit Namen "Atoll" heruntergeladen. Der Vorteil gegenüber anderen savegames war die große Stadt ohne Mods installieren zu müssen. Denn Mods haben bei meinen Tests die Leistung stark verschlechtert und sind wieder runter geflogen.
Ein Fehler meinerseits ist der überlaufende VRam. Die 2GB sind dauerhaft voll und sowas sollte man vermeiden. Texturen auf low anstatt high bringen VRAm auf 1500MB runter aber nur 2 FPS mehr und die Frametimes bleiben auch ähnlich.
Gerne hätte ich eine niedrigere Kamerafahrt gemacht, ein neues Gebiet hochgezogen oder ähnliches. Leider ließ die Reproduzierbarkeit dies nicht zu. Deshalb die starre Kameraposition mittig über der Stadt. Die 40s fangen eine gute Auswahl an kleinen Ausreißern ein und für jede Messung lade ich das savegame neu. Da sich das Stadtbild leicht verändert messe ich nicht direkt hintereinander sondern nehme die Ladezeiten in Kauf um zuverlässig die gleiche Situation zu messen.
Insgesamt bin ich mit dem Test ganz zufrieden. Es ist reproduzierbar, zeigt signifikante Unterschiede für anderen CPU-Takt, RAM-Takt oder den Wechsel von 8 auf 4 Kerne, sowie durch ausschalten von SMT.
https://www.youtube.com/watch?v=IY0CkOHgbwI&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=1
Ein reines Multiplayerspiel sollte man natürlich im Multiplayer testen und am besten in einer Kampfszene, in der es besonders auf die Performance ankommt. Live ist das leider nicht möglich aber glücklicherweise ist die Replayfunktion so gut wie live, nur ohne Internet Einflüsse.
Denn die Replayfunktion lässt das ganze Spielgeschehen mit allen Spielereingaben neu berechnen und ablaufen. Ich habe selbst gespielt und an Stellen an denen ich Ruckler gespürt habe, waren diese im Replay reproduzierbar genauer habe ich das bei Starcraft 2 untersucht, das die gleiche Methode verwendet.
Weil ich es selbst nicht wirklich spiele habe ich mir ein Replay aus dem Internet besorgt und einen Gruppenkampf herausgesucht. Weil der ingame Timer nicht perfekt der Echtzeit entspricht, und leichten Einflüssen durch die CPU Leistung unterliegt, habe ich Start und Endpunkt manuell gewählt. Dabei orientiere ich mich an dem ingame Timer von 5:55 bis 6:55. Auch lade ich nicht neu sondern spule das Replay zwischen den Messungen zurück.
Mit dem Test bin ich recht zufrieden. Die CPU könnte besser ausgelastet werden, so hängt man trotz maximaler Grafikeinstellungen im CPU Limit.
Reproduzierbarkeit ist ganz gut und die Szene ist typisch für das Spiel.
Vor allem die Eigenarten der Frametimes sind für mich sehr interessant.
Ein reines Multiplayerspiel sollte man natürlich im Multiplayer testen und am besten in einer Kampfszene, in der es besonders auf die Performance ankommt. Live ist das leider nicht möglich aber glücklicherweise ist die Replayfunktion so gut wie live, nur ohne Internet Einflüsse.
Denn die Replayfunktion lässt das ganze Spielgeschehen mit allen Spielereingaben neu berechnen und ablaufen. Ich habe selbst gespielt und an Stellen an denen ich Ruckler gespürt habe, waren diese im Replay reproduzierbar genauer habe ich das bei Starcraft 2 untersucht, das die gleiche Methode verwendet.
Weil ich es selbst nicht wirklich spiele habe ich mir ein Replay aus dem Internet besorgt und einen Gruppenkampf herausgesucht. Weil der ingame Timer nicht perfekt der Echtzeit entspricht, und leichten Einflüssen durch die CPU Leistung unterliegt, habe ich Start und Endpunkt manuell gewählt. Dabei orientiere ich mich an dem ingame Timer von 5:55 bis 6:55. Auch lade ich nicht neu sondern spule das Replay zwischen den Messungen zurück.
Mit dem Test bin ich recht zufrieden. Die CPU könnte besser ausgelastet werden, so hängt man trotz maximaler Grafikeinstellungen im CPU Limit.
Reproduzierbarkeit ist ganz gut und die Szene ist typisch für das Spiel.
Vor allem die Eigenarten der Frametimes sind für mich sehr interessant.
https://www.youtube.com/watch?v=hjB8IsT9Vjs&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=3
Ein Negativbeispiel von einem Benchmark.
Obwohl es integriert ist und man als Tester nur im richtigen Moment Start drücken muss, gibt es hier eine Reihe Fallstricke.
So startet die Szene direkt in die Action und direkt am Anfang gibt es Schwankungen, welche den Zeitpunkt zu dem die Messung gestartet wird kritisch werden lassen. Der Szenenwechsel bei 17s kommt mit sehr unregelmäßigem Stottern daher. Die weglaufenden Zivilisten werden scheinbar erst beim Szenenwechsel hereingeladen und halten den Ablauf auf.
Positiv ist, das Schaden und Geschehen scheinbar neu berechnet werden, wobei es jedoch eine Zufallskomponente gibt, die dafür sorgt, dass Personen manchmal nicht sterben obwohl sie es sollten, ein paar Schritte aus dem bild laufen anstatt direkt loszuschießen usw. Das verschlechtert die Reproduzierbarkeit stark.
Die Messung endet nach 60s automatisch aber genau zu diesem Zeitpunkt gibt es nochmal eine Explosion. Auch der Endpunkt ist also schlecht gewählt.
Und dann kommen wir zum großen Punkt Nvidias PhysX. Die ganze Szene ist voll davon und hier gibt es einen großen Fairnesskonflikt.....weil es eine Art Negativbeispiel sein soll, ist es natürlich trotzdem an. Man kann aber entscheiden ob es auf der CPU oder GPU gerechnet wird und da ist man im Konflikt od es sinnvoll auf der GPU(nur bei Nvidia möglich) oder vergleichbar auf der CPU, gemacht werden soll.
Ich habe mich für die Berechnung auf der CPU entschieden, was zu der schlechten Performance und den vielen Rucklern führt. Sinnvoll oder nicht...ich bin mir selbst nicht sicher
Ein Negativbeispiel von einem Benchmark.
Obwohl es integriert ist und man als Tester nur im richtigen Moment Start drücken muss, gibt es hier eine Reihe Fallstricke.
So startet die Szene direkt in die Action und direkt am Anfang gibt es Schwankungen, welche den Zeitpunkt zu dem die Messung gestartet wird kritisch werden lassen. Der Szenenwechsel bei 17s kommt mit sehr unregelmäßigem Stottern daher. Die weglaufenden Zivilisten werden scheinbar erst beim Szenenwechsel hereingeladen und halten den Ablauf auf.
Positiv ist, das Schaden und Geschehen scheinbar neu berechnet werden, wobei es jedoch eine Zufallskomponente gibt, die dafür sorgt, dass Personen manchmal nicht sterben obwohl sie es sollten, ein paar Schritte aus dem bild laufen anstatt direkt loszuschießen usw. Das verschlechtert die Reproduzierbarkeit stark.
Die Messung endet nach 60s automatisch aber genau zu diesem Zeitpunkt gibt es nochmal eine Explosion. Auch der Endpunkt ist also schlecht gewählt
.Und dann kommen wir zum großen Punkt Nvidias PhysX. Die ganze Szene ist voll davon und hier gibt es einen großen Fairnesskonflikt.....weil es eine Art Negativbeispiel sein soll, ist es natürlich trotzdem an
. Man kann aber entscheiden ob es auf der CPU oder GPU gerechnet wird und da ist man im Konflikt od es sinnvoll auf der GPU(nur bei Nvidia möglich) oder vergleichbar auf der CPU, gemacht werden soll.Ich habe mich für die Berechnung auf der CPU entschieden, was zu der schlechten Performance und den vielen Rucklern führt. Sinnvoll oder nicht...ich bin mir selbst nicht sicher
https://www.youtube.com/watch?v=5YqOCKvncCY&index=4&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Ein aktuelles Spiel, das mit vielen Kernen umgehen kann und halbwegs beliebt ist. Obwohl ich Mafia 1 ziemlich gut fand und auch Mafia 2 nicht schlecht, reizt mich Mafia 3 im Moment nicht. Daher habe ich nur die Demo heruntergeladen. Ich hatte in der Demo ein Problem eine CPU fordernder Szene zu finden. Ich habe alle Grafikeinstellungen auf low und die Auflösung reduziert um irgendwie die GPU zu entlasten. Das anspruchsvollste schien Autofahren und Unfälle bauen zu sein. Daher habe ich genau das gemacht. Mit Polizei wurde es schlecht reproduzierbar also besser ohne. Und um zuverlässig P99 und P99.9 zu messen, musste ich sehr lange messen. Die avg FPS bleiben eigentlich immer gleich, aber mit weniger Kernen sieht man durchaus große Unterschiede bei den schlechten Frametimes.
Ein aktuelles Spiel, das mit vielen Kernen umgehen kann und halbwegs beliebt ist. Obwohl ich Mafia 1 ziemlich gut fand und auch Mafia 2 nicht schlecht, reizt mich Mafia 3 im Moment nicht. Daher habe ich nur die Demo heruntergeladen. Ich hatte in der Demo ein Problem eine CPU fordernder Szene zu finden. Ich habe alle Grafikeinstellungen auf low und die Auflösung reduziert um irgendwie die GPU zu entlasten. Das anspruchsvollste schien Autofahren und Unfälle bauen zu sein. Daher habe ich genau das gemacht. Mit Polizei wurde es schlecht reproduzierbar also besser ohne. Und um zuverlässig P99 und P99.9 zu messen, musste ich sehr lange messen. Die avg FPS bleiben eigentlich immer gleich, aber mit weniger Kernen sieht man durchaus große Unterschiede bei den schlechten Frametimes.
https://www.youtube.com/watch?v=bZO0f3dR9_M&index=5&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Prey läuft generell ziemlich gut, aber es ist neu und gerade weil es so gut läuft ist es ein gutes Beispiel dafür wie Frametimes idealerweise aussehen sollten. Ich weiß nicht ob es bessere Szenen zum testen gibt, weil ich selbst noch nicht sonderlich weit gespielt habe.
Ich fand die Lobby mit den vielen Fenstern ganz ok. Das Turret ist ein sehr zuverlässiger Gegner und das Explodieren der Gasflasche am Ende, deckt etwas den Physikpart ab. Mein komplizierter Ablauf am Anfang ist dämlich gewählt, hat aber überraschenderweise keinen wirklichen Einfluss auf die gute Reproduzierbarkeit.
Obwohl ich mir nicht viel Mühe gegeben habe, sind die Ergebnisse gut gelungen....Für einen richtigen Test würde ich aber lieber nach einer anderen Szene plus besserem Ablauf suchen.
Edit: was mir mit der GTX680 und niedrigen Texturen nicht aufgefallen war, ist dass das Spiel bei höheren Textureinstellungen korrigierend eingreift. Als ich die GTX680(2GB VRam) mit 1440p und Ultra Texturen überlasten wollte, lief das Spiel überraschend gut....sah aber bescheiden aus! Denn trotz Ultra Einstellung werden nur rudimentäre, matschige Farbkleckse als Texturen verwendet....dann aber zeitweise und vereinzelt wieder auf Ultra Texturen geschaltet. Reproduzierbare Messungen waren daher nicht möglich. Wenn man den VRam nicht ausnutzt wird es vermutlich gehen, aber eigentlich markiert dieses "Feature" das Spiel als Benchmark ungeeignet.
Prey läuft generell ziemlich gut, aber es ist neu und gerade weil es so gut läuft ist es ein gutes Beispiel dafür wie Frametimes idealerweise aussehen sollten. Ich weiß nicht ob es bessere Szenen zum testen gibt, weil ich selbst noch nicht sonderlich weit gespielt habe.
Ich fand die Lobby mit den vielen Fenstern ganz ok. Das Turret ist ein sehr zuverlässiger Gegner und das Explodieren der Gasflasche am Ende, deckt etwas den Physikpart ab. Mein komplizierter Ablauf am Anfang ist dämlich gewählt, hat aber überraschenderweise keinen wirklichen Einfluss auf die gute Reproduzierbarkeit.
Obwohl ich mir nicht viel Mühe gegeben habe, sind die Ergebnisse gut gelungen....Für einen richtigen Test würde ich aber lieber nach einer anderen Szene plus besserem Ablauf suchen.
Edit: was mir mit der GTX680 und niedrigen Texturen nicht aufgefallen war, ist dass das Spiel bei höheren Textureinstellungen korrigierend eingreift. Als ich die GTX680(2GB VRam) mit 1440p und Ultra Texturen überlasten wollte, lief das Spiel überraschend gut....sah aber bescheiden aus! Denn trotz Ultra Einstellung werden nur rudimentäre, matschige Farbkleckse als Texturen verwendet....dann aber zeitweise und vereinzelt wieder auf Ultra Texturen geschaltet. Reproduzierbare Messungen waren daher nicht möglich. Wenn man den VRam nicht ausnutzt wird es vermutlich gehen, aber eigentlich markiert dieses "Feature" das Spiel als Benchmark ungeeignet.
https://www.youtube.com/watch?v=LkkRViulpSE&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=6
Der simple 2D-Comic stil macht die Grafikkarte praktisch unwichtig und die trotzdem niedrige Performance das Spiel zu einem guten CPU-Testkandidaten.
Eigentlich braucht man für so ein Spiel keine tollen Frametimes. Aber ein nerviger Part beim Spielen ist, dass die Zeit langsamer läuft wenn die Performance zu stark sinkt. Gerade das Warten auf einen Shakedown kann dann trotz Geschwindigkeit auf Stufe 3 zur Geduldsprobe werden.
Eigentlich wollte die Zeit stoppen bis der Shakedown vorbei ist, aber das hat sich als unbrauchbar erwiesen, weil manche Wärter sich festbuggen, Ewigkeiten hinter Gefangenen herlaufen, Kämpfe starten usw.
Daher bin ich doch auf die FPS/Frametime Messung zurückgegangen. Denn mit mehr FPS läuft das Spiel schneller und dann ist auch der Shakedown schneller vorbei.
Hier verwende ich ein eigenes Savegame. Das Gefängnis ist nicht die aktuellste Version aber bereits relativ komplex und drückt die Performance definitiv in kritische Bereiche. Die Geschwindigkeit wird auf Stufe drei erhöht und der Shakedown gestartet, während die Kamera ganz rausgezoomt ist und das ganze Gefängnisgelände im Sichtbereich ist.
Ich habe die Messung auf 2min gestellt und das dauert schon sehr lange.....Die Reproduzierbarkeit ist gut und man könnte sicherlich auch mit weniger Testzeit klarkommen. Die zusätzliche Genauigkeit hat es allerdings ermöglicht auch feine Unterschiede zwischen der 2+2 und 4+0 Konfiguration bei Ryzen zu erkennen.
Mir gefällt der Test, ein weiteres gutes Beispiel für hohen Anspruch an CPU und RAM.
Der simple 2D-Comic stil macht die Grafikkarte praktisch unwichtig und die trotzdem niedrige Performance das Spiel zu einem guten CPU-Testkandidaten.
Eigentlich braucht man für so ein Spiel keine tollen Frametimes. Aber ein nerviger Part beim Spielen ist, dass die Zeit langsamer läuft wenn die Performance zu stark sinkt. Gerade das Warten auf einen Shakedown kann dann trotz Geschwindigkeit auf Stufe 3 zur Geduldsprobe werden.
Eigentlich wollte die Zeit stoppen bis der Shakedown vorbei ist, aber das hat sich als unbrauchbar erwiesen, weil manche Wärter sich festbuggen, Ewigkeiten hinter Gefangenen herlaufen, Kämpfe starten usw.
Daher bin ich doch auf die FPS/Frametime Messung zurückgegangen. Denn mit mehr FPS läuft das Spiel schneller und dann ist auch der Shakedown schneller vorbei.
Hier verwende ich ein eigenes Savegame. Das Gefängnis ist nicht die aktuellste Version aber bereits relativ komplex und drückt die Performance definitiv in kritische Bereiche. Die Geschwindigkeit wird auf Stufe drei erhöht und der Shakedown gestartet, während die Kamera ganz rausgezoomt ist und das ganze Gefängnisgelände im Sichtbereich ist.
Ich habe die Messung auf 2min gestellt und das dauert schon sehr lange.....Die Reproduzierbarkeit ist gut und man könnte sicherlich auch mit weniger Testzeit klarkommen. Die zusätzliche Genauigkeit hat es allerdings ermöglicht auch feine Unterschiede zwischen der 2+2 und 4+0 Konfiguration bei Ryzen zu erkennen.
Mir gefällt der Test, ein weiteres gutes Beispiel für hohen Anspruch an CPU und RAM.
Ich hatte noch nicht die Zeit das Spiel zu spielen und dachte diese "Herausforderungen" wären eine gute Möglichkeit eine nette Testszene zu finden....leider nein . Ich hatte eine vernünftige Szene mit Rennen, Klettern, Springen ohne Gegner gefunden und war halb durch mit dem testen, als am nächsten Tag die Herausforderung angepasst war und Lara mit einem Riesenkopf gestraft war....selbst zusammengestellt, konnte ich die Szene nicht mehr ohne Gegner oder wilde Tiere im Testbereich konfigurieren.
Auch habe ich gehört, das verschiedene Bereiche des Spiels verschiedene Marken bevorzugen und das zu untersuchen war mir zu aufwendig für ein Spiel, das auch so schon gut zu laufen scheint.
Den integrierten Benchmark fand ich nicht passend...erstens gibt es Szenewechsel, die die Auswertung der Perzentil Werte und Grenzwertüberschreitungen zunichte machen und die Kamerafahrten haben auch nicht mit dem Spielgeschehen zu tun.
. Ich hatte eine vernünftige Szene mit Rennen, Klettern, Springen ohne Gegner gefunden und war halb durch mit dem testen, als am nächsten Tag die Herausforderung angepasst war und Lara mit einem Riesenkopf gestraft war....selbst zusammengestellt, konnte ich die Szene nicht mehr ohne Gegner oder wilde Tiere im Testbereich konfigurieren. Auch habe ich gehört, das verschiedene Bereiche des Spiels verschiedene Marken bevorzugen und das zu untersuchen war mir zu aufwendig für ein Spiel, das auch so schon gut zu laufen scheint.
Den integrierten Benchmark fand ich nicht passend...erstens gibt es Szenewechsel, die die Auswertung der Perzentil Werte und Grenzwertüberschreitungen zunichte machen und die Kamerafahrten haben auch nicht mit dem Spielgeschehen zu tun.
https://www.youtube.com/watch?v=niq48FIFTow&index=7&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Hier nehme ich direkt zwei Testszenen auf.
Grundlage ist eine "Historische Schlacht". Die Armeen sind groß aber nicht übertrieben. Es fängt mit einem Intro zu den Hintergründen der Schlacht an, dabei wechselt die Kamera immer wieder die Position während die Truppen sich positionieren. Danach beginnt die eigentliche Schlacht. Dabei wähle ich alle Truppen an und befehle rennend eine mittige Infantrieeinheit der Gegner anzugreifen. ich starte die Schlacht und die Messung. Die Messung hab ich auf 1min eingestellt, weil bei weniger Zeit zu wenig Kampf stattfindet(die Truppen müssen ja erstmal ankommen). Bei längerer Messung würde die Schlacht zu stark variieren, Truppen rennen weg, Anführer sterben usw.
Weil die Messung auf 1min festgelegt ist nehme ich auch vom Intro nur 1min auf.
Dabei ist das Intro super reproduzierbar. 1min fest definierter Ablauf klingt optimal. Aber relevant ist es eher weniger, denn das Kampfgeschehen drückt die Performance stark und fordert mehr von der CPU als nur FPS rauszuhauen.
Die Messung mit Kampfszene hat außerdem keine Kamerasprünge.
Fraglich ist ob das Spiel überhaupt Sinn macht. Für mich schon, da ich erst letztes Jahr Europa wieder unter weströmische Herrschaft gestellt habe. Aber für viele ist es wahrscheinlich sinnlos.
Es ist aber ein gutes Beispiel für reine singlecore Performance, die auch aktuelle Rechner in die Knie zwingt.
Hier nehme ich direkt zwei Testszenen auf.
Grundlage ist eine "Historische Schlacht". Die Armeen sind groß aber nicht übertrieben. Es fängt mit einem Intro zu den Hintergründen der Schlacht an, dabei wechselt die Kamera immer wieder die Position während die Truppen sich positionieren. Danach beginnt die eigentliche Schlacht. Dabei wähle ich alle Truppen an und befehle rennend eine mittige Infantrieeinheit der Gegner anzugreifen. ich starte die Schlacht und die Messung. Die Messung hab ich auf 1min eingestellt, weil bei weniger Zeit zu wenig Kampf stattfindet(die Truppen müssen ja erstmal ankommen). Bei längerer Messung würde die Schlacht zu stark variieren, Truppen rennen weg, Anführer sterben usw.
Weil die Messung auf 1min festgelegt ist nehme ich auch vom Intro nur 1min auf.
Dabei ist das Intro super reproduzierbar. 1min fest definierter Ablauf klingt optimal. Aber relevant ist es eher weniger, denn das Kampfgeschehen drückt die Performance stark und fordert mehr von der CPU als nur FPS rauszuhauen.
Die Messung mit Kampfszene hat außerdem keine Kamerasprünge.
Fraglich ist ob das Spiel überhaupt Sinn macht. Für mich schon, da ich erst letztes Jahr Europa wieder unter weströmische Herrschaft gestellt habe. Aber für viele ist es wahrscheinlich sinnlos
.Es ist aber ein gutes Beispiel für reine singlecore Performance, die auch aktuelle Rechner in die Knie zwingt.
https://www.youtube.com/watch?v=079Ft0-CQCc&index=8&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Viele Parallelen zu Heroes of the Storm. Messung passiert im Replay, CPU limitiert, spricht gut auf Ram an, ist beides von Blizzard...usw.
Die Szene gefällt mir. Vielen Dank an ClamorofSoul! Es ist sicherlich ein Multiplayer Worst-Case-Szenario, auch in einem 4 vs.4, aber es ist nicht ganz unrealistisch und in einigen coop-Missionen finden sich noch extremere Anforderungen.
Ich füge hier nochmal das Beispiel von weiter oben ein:
Man erkennt gut, wie die Vormessung viel mehr Ausreißer hat, weshalb ich diese nicht bewerte.
Um zu klären ob sich die Performance im live Spielen überhaupt mit dem Replay vergleiche lässt habe ich eine Reihe Tests gemacht. Hier ein Beispiel auf einem 1 vs. 1:
Es handelt sich um einen kleinen Kampf nach ca 7min aus dem erste Spiel des Tages. Die Messung während des Spielens wird verglichen mit der Vormessung(hier Messung 1). Dazwischen lag ein PC Neustart.
Wie man an den Graphen und den avg FPS, P99 und P99.9 Werten sieht, liefert die Replay Messung schlechtere Werte als das live Spielerlebnis.
Hier sehen wir jetzt den Vergleich von live zur zweiten Messung des Replays. Beide Messungen zeigen ein vergleichbares Gesamtbild mit ähnlich großen und recht zufällig verteilten mittelgroßen Ausreißern, allerdings hat die live-Messung 2-4 größere Ausreißer, die in der zweiten Replay Messung fehlen.
Die Replay Messung ist in diesem Fall im Schnitt 3,9% besser als die liveperformance. Bei den P99 sind es 3% und bei den P99.9 durch die größeren Ausreißer sogar 21,7%.
Zur Vollständigkeit hier auch noch der Vergleich von Messung 1(vormessung) zu Messung 2:
Und ein Vergleich von Coop gegeb Vormessung:
Diese Beispiele und eine Reihe weiterer Tests bestätigen mich in der Annahme, dass Starcraft 2 Probleme mit Nachladerucklern hat. Keine super dramatischen, irgendwo muss auf Daten gewartet werden. Spielt man oder lässt das Replay laufen, werden die Daten nach und nach hereingeladen und ein zurückspulen des Replays eliminiert die Ausreißer. Während dem Spielen passiert das gleiche, aber da gibt es kein zurückspulen...die Daten müssen also im vorherigen Verlauf schon einmal hereingeladen worden sein, sonst hat man Pech. Da das Spiel logischerweise schon einige Minuten läuft, ich im Replay aber nicht das Spiel in Echtzeit angucken möchte, spule ich das Geschehen vor und überspule daher die Möglichkeit Daten hereingeladen zu haben. Deshalb läuft die Vormessung im Replay schlechter als die live-Messung. Die Nachfolgenden Messungen im Replay aber besser als die live-Messung.
Es ist schwer zu testen und für vage Aussagen war mir die Zeit zu schade....aber ich denke das die live Performance immer besser wird, um so mehr Spiele man an dem Tag schon gespielt hat.
Meine Entscheidung Starcraft 2 mit den Messungen 2-4 aus einem Replay zu benchmarken, ist also mit dem Makel behaftet, dass das live Spielgefühl aufgrund von Nachladeunterbrechungen schlechter sein wird.
Gut ist die Tatsache, das sich die Frametimes abseits des Nachladens gleich verhalten. Das Replay funktioniert also so wie ein erneutes Spielen der gleichen Situation. Die Vormessung im Replay ist schlechter als live und zusätzlich ist die Höhe der Ausreißer stark schwankend. Beides disqualifiziert sie meiner Meinung nach für eine Benchmarkmessung. Die nachfolgenden Replay-Messungen stehen für die reine CPU/Ram Leistung ohne zufällige Probleme der Programmierung bei guter Reproduzierbarkeit.
Viele Parallelen zu Heroes of the Storm. Messung passiert im Replay, CPU limitiert, spricht gut auf Ram an, ist beides von Blizzard...usw.
Die Szene gefällt mir. Vielen Dank an ClamorofSoul! Es ist sicherlich ein Multiplayer Worst-Case-Szenario, auch in einem 4 vs.4, aber es ist nicht ganz unrealistisch und in einigen coop-Missionen finden sich noch extremere Anforderungen.
Ich füge hier nochmal das Beispiel von weiter oben ein:
Man erkennt gut, wie die Vormessung viel mehr Ausreißer hat, weshalb ich diese nicht bewerte.
Um zu klären ob sich die Performance im live Spielen überhaupt mit dem Replay vergleiche lässt habe ich eine Reihe Tests gemacht. Hier ein Beispiel auf einem 1 vs. 1:
Es handelt sich um einen kleinen Kampf nach ca 7min aus dem erste Spiel des Tages. Die Messung während des Spielens wird verglichen mit der Vormessung(hier Messung 1). Dazwischen lag ein PC Neustart.
Wie man an den Graphen und den avg FPS, P99 und P99.9 Werten sieht, liefert die Replay Messung schlechtere Werte als das live Spielerlebnis.
Hier sehen wir jetzt den Vergleich von live zur zweiten Messung des Replays. Beide Messungen zeigen ein vergleichbares Gesamtbild mit ähnlich großen und recht zufällig verteilten mittelgroßen Ausreißern, allerdings hat die live-Messung 2-4 größere Ausreißer, die in der zweiten Replay Messung fehlen.
Die Replay Messung ist in diesem Fall im Schnitt 3,9% besser als die liveperformance. Bei den P99 sind es 3% und bei den P99.9 durch die größeren Ausreißer sogar 21,7%.
Zur Vollständigkeit hier auch noch der Vergleich von Messung 1(vormessung) zu Messung 2:
Und ein Vergleich von Coop gegeb Vormessung:
Diese Beispiele und eine Reihe weiterer Tests bestätigen mich in der Annahme, dass Starcraft 2 Probleme mit Nachladerucklern hat. Keine super dramatischen, irgendwo muss auf Daten gewartet werden. Spielt man oder lässt das Replay laufen, werden die Daten nach und nach hereingeladen und ein zurückspulen des Replays eliminiert die Ausreißer. Während dem Spielen passiert das gleiche, aber da gibt es kein zurückspulen...die Daten müssen also im vorherigen Verlauf schon einmal hereingeladen worden sein, sonst hat man Pech. Da das Spiel logischerweise schon einige Minuten läuft, ich im Replay aber nicht das Spiel in Echtzeit angucken möchte, spule ich das Geschehen vor und überspule daher die Möglichkeit Daten hereingeladen zu haben. Deshalb läuft die Vormessung im Replay schlechter als die live-Messung. Die Nachfolgenden Messungen im Replay aber besser als die live-Messung.
Es ist schwer zu testen und für vage Aussagen war mir die Zeit zu schade....aber ich denke das die live Performance immer besser wird, um so mehr Spiele man an dem Tag schon gespielt hat.
Meine Entscheidung Starcraft 2 mit den Messungen 2-4 aus einem Replay zu benchmarken, ist also mit dem Makel behaftet, dass das live Spielgefühl aufgrund von Nachladeunterbrechungen schlechter sein wird.
Gut ist die Tatsache, das sich die Frametimes abseits des Nachladens gleich verhalten. Das Replay funktioniert also so wie ein erneutes Spielen der gleichen Situation. Die Vormessung im Replay ist schlechter als live und zusätzlich ist die Höhe der Ausreißer stark schwankend. Beides disqualifiziert sie meiner Meinung nach für eine Benchmarkmessung. Die nachfolgenden Replay-Messungen stehen für die reine CPU/Ram Leistung ohne zufällige Probleme der Programmierung bei guter Reproduzierbarkeit.
https://www.youtube.com/watch?v=loa5pGzpy58&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=9
Ich interessiere mich nicht wirklich für das Spiel....aber man kann es einige Stunden umsonst spielen und den integrierten Benchmark laufen lassen zählt nicht in diese Zeit rein. Ich habe den Benchmark oft bei anderen Testern gesehen und dachte mir: "Warum nicht?"
Problematisch für einen Benchmark.....es kommen noch ab und zu Updates und seit ich teste, gab es mindestens ein Update, das massiv die Performance verbessert hat. Jetzt sind die Frametimes echt gut, aber vorher war es voller Mikroschwankungen und Ausreißer.
Die Daten die ich jetzt habe sind alle kurz hintereinander entstanden und daher vergleichbar, aber inzwischen gab es mindestens noch ein Update und auch wenn ich nicht weiß ob sich die Performance geändert hat, so müsste ich doch alles neu testen sobald ich weitere Messungen machen möchte.
Auch sonst bin ich nicht begeistert von dem Benchmark. Kurz nach dem Start auf dem Dach kann es zu einem schlecht reproduzierbaren Ruckler kommen....Mal ist er da, mal nicht und mal stark, mal schwach.
Meine alte Grafikkarte ist zu schlecht für das Spiel und ich muss sehr niedrige Einstellungen wählen.
Der Einfluss der CPU ist kaum relevant. Selbst mein alter i5 auf 2,8GHz heruntergetaktet hat keine Probleme.
Eventuell würde im eigentlichen Spiel und mit anderen online Spielern eine höhere CPU Last erzeugt.
Ich interessiere mich nicht wirklich für das Spiel....aber man kann es einige Stunden umsonst spielen und den integrierten Benchmark laufen lassen zählt nicht in diese Zeit rein. Ich habe den Benchmark oft bei anderen Testern gesehen und dachte mir: "Warum nicht?"
Problematisch für einen Benchmark.....es kommen noch ab und zu Updates und seit ich teste, gab es mindestens ein Update, das massiv die Performance verbessert hat. Jetzt sind die Frametimes echt gut, aber vorher war es voller Mikroschwankungen und Ausreißer.
Die Daten die ich jetzt habe sind alle kurz hintereinander entstanden und daher vergleichbar, aber inzwischen gab es mindestens noch ein Update und auch wenn ich nicht weiß ob sich die Performance geändert hat, so müsste ich doch alles neu testen sobald ich weitere Messungen machen möchte.
Auch sonst bin ich nicht begeistert von dem Benchmark. Kurz nach dem Start auf dem Dach kann es zu einem schlecht reproduzierbaren Ruckler kommen....Mal ist er da, mal nicht und mal stark, mal schwach.
Meine alte Grafikkarte ist zu schlecht für das Spiel und ich muss sehr niedrige Einstellungen wählen.
Der Einfluss der CPU ist kaum relevant. Selbst mein alter i5 auf 2,8GHz heruntergetaktet hat keine Probleme.
Eventuell würde im eigentlichen Spiel und mit anderen online Spielern eine höhere CPU Last erzeugt.
https://www.youtube.com/watch?v=qoORTnuP1C4&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=10
Kein populäres Spiel. Obwohl ich die ersten zwei Teile super fand und auch der dritte mit ein paar Mods gut war, konnte ich mich mit diesem nicht anfreunden.
Aber wie schon bei The Devision dachte ich mir: "Warum nicht?"
Die Ergebnisse sind ähnlich....meine Grafikkarte ist schwach, das Spiel läuft gut.
Anders als bei The Devision senkt ein niedrigerer CPU Takt die avg FPS, aber selbst die P99.9 bleiben gut.
Als CPU-Test uninteressant.
Es ist ein AMD Evolved Titel, scheint aber auf Nvidia Karten trotzdem gut zu laufen.
Kein populäres Spiel. Obwohl ich die ersten zwei Teile super fand und auch der dritte mit ein paar Mods gut war, konnte ich mich mit diesem nicht anfreunden.
Aber wie schon bei The Devision dachte ich mir: "Warum nicht?"
Die Ergebnisse sind ähnlich....meine Grafikkarte ist schwach, das Spiel läuft gut.
Anders als bei The Devision senkt ein niedrigerer CPU Takt die avg FPS, aber selbst die P99.9 bleiben gut.
Als CPU-Test uninteressant.
Es ist ein AMD Evolved Titel, scheint aber auf Nvidia Karten trotzdem gut zu laufen.
https://www.youtube.com/watch?v=S0dvhns3xJU&index=11&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Und noch ein integrierter Benchmark.
Was soll ich sagen...um das heftige GPU Limit zu mindern habe ich so lange an den Einstellungen gefeilt, bis ich die höchste CPU Auslastung hatte. Trotzdem bleibt man völlig GPU limitiert und die FPS fallen nie unter 120.
Auf dem i5 ab und zu aber nichts annährend relevantes.
Ich habe versucht eine Spielszene zu nehmen und hatte eine ganz nette. Mit ganz gut reproduzierbarem Kampf gegen zwei Gegner und anschließendem kurzem klettern mit hochschlagenden Wellen usw.
Aber das komische Speichersystem hat die Szene ruiniert, als ich einen Schritt zu viel gemacht habe und der nächste savepoint aktiviert wurde.
Also auch hier... uninteressant....die Benchmarkszene sowieso weil nichts passiert.
Und noch ein integrierter Benchmark.
Was soll ich sagen...um das heftige GPU Limit zu mindern habe ich so lange an den Einstellungen gefeilt, bis ich die höchste CPU Auslastung hatte. Trotzdem bleibt man völlig GPU limitiert und die FPS fallen nie unter 120.
Auf dem i5 ab und zu aber nichts annährend relevantes.
Ich habe versucht eine Spielszene zu nehmen und hatte eine ganz nette. Mit ganz gut reproduzierbarem Kampf gegen zwei Gegner und anschließendem kurzem klettern mit hochschlagenden Wellen usw.
Aber das komische Speichersystem hat die Szene ruiniert, als ich einen Schritt zu viel gemacht habe und der nächste savepoint aktiviert wurde.
Also auch hier... uninteressant....die Benchmarkszene sowieso weil nichts passiert.
https://www.youtube.com/watch?v=mBtQFy-amas&index=12&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
https://www.youtube.com/watch?v=wsCwJrYESmA&index=13&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Ein altes Spiel aber weil es zeitweise verschenkt wurde sicherlich bei vielen im Besitz.
Technisch ist es nicht wirklich auf der Höhe der Zeit(oder seiner Zeit). Szene 1 ist aus dem Händlerviertel und eine der fordernsten Stellen im Spiel. Ich erinnere mich noch was das auf meinem alten c2d E6600 für eine Ruckelei war.
Und auch jetzt ist die Szene durchsetzt von gelegentlichem Stottern, das man sogar im 30FPS Video sehen kann.
Es gibt glaube ich noch eine forderndere Szene kurz vorm Ende aber da ist man schnell durch und im Händlerviertel verbringt man als Spieler einiges an Zeit. Trotzdem sind die anderen Bereiche des Spiels nicht mit diesem Stottern geplagt und laufen auch insgesamt besser. Daher habe ich noch eine zweite Szene getestet. Den Sumpf besucht man ebenfalls oft und ist CPU limitiert.
Bei beiden Szenen laufe ich eine größere Runde. Keine Gegner, weil diese gerade im Sumpf in sehr unterschiedlicher Anzahl auftauchen. Kämpfen stresst die CPU auch nicht spürbar stärker.
Erst dachte ich das Spiel ist eine reine singlecore Anwendung, aber wenn man dem Prozess nur einen Kern zuweist sinkt die Leistung nochmal spürbar. Nur die Threads 0-2 zuzuweisen hat sich als optimal erwiesen. Wurde zum benchmarken aber nur für Sondertests gemacht.
https://www.youtube.com/watch?v=wsCwJrYESmA&index=13&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz
Ein altes Spiel aber weil es zeitweise verschenkt wurde sicherlich bei vielen im Besitz.
Technisch ist es nicht wirklich auf der Höhe der Zeit(oder seiner Zeit). Szene 1 ist aus dem Händlerviertel und eine der fordernsten Stellen im Spiel. Ich erinnere mich noch was das auf meinem alten c2d E6600 für eine Ruckelei war
.Und auch jetzt ist die Szene durchsetzt von gelegentlichem Stottern, das man sogar im 30FPS Video sehen kann.
Es gibt glaube ich noch eine forderndere Szene kurz vorm Ende aber da ist man schnell durch und im Händlerviertel verbringt man als Spieler einiges an Zeit. Trotzdem sind die anderen Bereiche des Spiels nicht mit diesem Stottern geplagt und laufen auch insgesamt besser. Daher habe ich noch eine zweite Szene getestet. Den Sumpf besucht man ebenfalls oft und ist CPU limitiert.
Bei beiden Szenen laufe ich eine größere Runde. Keine Gegner, weil diese gerade im Sumpf in sehr unterschiedlicher Anzahl auftauchen. Kämpfen stresst die CPU auch nicht spürbar stärker.
Erst dachte ich das Spiel ist eine reine singlecore Anwendung, aber wenn man dem Prozess nur einen Kern zuweist sinkt die Leistung nochmal spürbar. Nur die Threads 0-2 zuzuweisen hat sich als optimal erwiesen. Wurde zum benchmarken aber nur für Sondertests gemacht.
https://www.youtube.com/watch?v=l89uyQTiv5s&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=14
Ich bin beim spielen noch nicht über Flotsam herausgekommen. Es mag später im Spiel größere Städte geben, die ein besserer Test sind. Aber auch hier werden 4 Kerne gut ausgelastet und es eignet sich als CPU Test.
Die Szene ist unnötig lang weil ich gerne viel abdecken wollte. Die Reproduzierbarkeit ist gut und man könnte die Szene sicherlich einkürzen.
Ich bin beim spielen noch nicht über Flotsam herausgekommen. Es mag später im Spiel größere Städte geben, die ein besserer Test sind. Aber auch hier werden 4 Kerne gut ausgelastet und es eignet sich als CPU Test.
Die Szene ist unnötig lang weil ich gerne viel abdecken wollte. Die Reproduzierbarkeit ist gut und man könnte die Szene sicherlich einkürzen.
https://www.youtube.com/watch?v=tu5Y4VG60_U&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=15
https://www.youtube.com/watch?v=0RoJ8ux-hzo&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=16
Szene 1 ist ein Lauf durch Novigrad bei Nacht. Betrunkene und Prostituierte trinken, tanzen und quatschen...es sind viele NPCs auf einem Haufen und das bringt die Spieleengine dazu, ab und zu Schluckauf zu bekommen. Da das Spiel generell GPU limitiert ist(vor allem mit meiner GPU), hängen die avg FPS so gut wie gar nicht von der CPU ab.
Interessant zu vergleichen ist die Menge des Stotterns. Hier gibt es einen riesen Einfluss bezüglich des verwendeten Betriebssystems.
Und das klärt meine Motivation im Hauptthread.....Windows 7 schafft es nicht die CPU richtig auszulasten und das führt bei der Engine zu sehr viel Stottern, wenn viele NPCs in der Nähe sind. Dafür muss es nichtmal Novigrad sein, auch in der Mitte von Dörfern legt das Spiel immer wieder kleine Gedenkpausen ein.
Als ich das erste mal den i5 mit Windows 10 getestet hatte und es so viel besser lief, dachte ich erst an eklatante Fehler meinerseits unter Windows 7. Aber auch eine frische Windows 7 Installation, nur die neusten Treiber und nur die nötigsten Programme konnte die alten Erfahrungen bestätigen.
Trotz 60FPS im Durchschnitt ein grausiges Erlebnis unter Windows 7.
57 gut spürbare Ausreißer über 50ms/unter 20FPS sind brutal. Und da das Spiel dabei immer kurz stockt, ist es schlimmer als andere Spiele, die mit unter 20 FPS laufen.
Eine genauere Betrachtung findet sich in einem extra Thread:
platzhalter
Hier geht es um die Testszene und diese gefällt mir ganz gut. Ich benutze zwar eine recht komplizierte Route und wenn es Ausreißer gibt, sind diese zufällig verteilt. Daher ist die Szene recht lang um diese Ausreißer zuverlässiger einzufangen. Auch laufe ich recht weit weg, was dafür sorgt, das man bei der nächsten Runde andere NPCs sieht. Wie schon an anderer Stelle beschrieben laufe ich eine Runde und starte die Messungen hintereinander anstatt neu zu laden. Das hat den Grund, dass man bei nach jedem neu laden erstmal vermehrt Schwankungen hat, die ich vermeiden möchte.
Die zweite Szene ist grob die Testsequenz von CB, die ich nachgestellt habe. Für einen Grafikkartentest sicherlich OK aber als CPU Test halte ich sie für ungeeignet.
Vergleicht man die CB Szene mit den ersten 25s der Novigrad-Szene unter Windows 7 zeigt sich wie wenig die CPU im Vergleich gefordert wird.
Zu*ge*ge*be*ner*ma*ßen relativieren sich die Unterschiede wenn wir auf Windows 10 wechseln.
Aber zumindest zeigen sich in Novigrad belastbare Unterschiede zwischen den CPUs und wenn man sich z.B. die Tests von DigitalFoundry anguckt, sieht man, dass mit einer besseren Grafikkarte sogar Unterschiede in den avg FPS relevant werden.
https://www.youtube.com/watch?v=0RoJ8ux-hzo&list=PLP9fskJGwUOS37j3lYztg2G610oISjXNz&index=16
Szene 1 ist ein Lauf durch Novigrad bei Nacht. Betrunkene und Prostituierte trinken, tanzen und quatschen...es sind viele NPCs auf einem Haufen und das bringt die Spieleengine dazu, ab und zu Schluckauf zu bekommen. Da das Spiel generell GPU limitiert ist(vor allem mit meiner GPU), hängen die avg FPS so gut wie gar nicht von der CPU ab.
Interessant zu vergleichen ist die Menge des Stotterns. Hier gibt es einen riesen Einfluss bezüglich des verwendeten Betriebssystems.
Und das klärt meine Motivation im Hauptthread.....Windows 7 schafft es nicht die CPU richtig auszulasten und das führt bei der Engine zu sehr viel Stottern, wenn viele NPCs in der Nähe sind. Dafür muss es nichtmal Novigrad sein, auch in der Mitte von Dörfern legt das Spiel immer wieder kleine Gedenkpausen ein.
Als ich das erste mal den i5 mit Windows 10 getestet hatte und es so viel besser lief, dachte ich erst an eklatante Fehler meinerseits unter Windows 7. Aber auch eine frische Windows 7 Installation, nur die neusten Treiber und nur die nötigsten Programme konnte die alten Erfahrungen bestätigen.
Trotz 60FPS im Durchschnitt ein grausiges Erlebnis unter Windows 7.
57 gut spürbare Ausreißer über 50ms/unter 20FPS sind brutal. Und da das Spiel dabei immer kurz stockt, ist es schlimmer als andere Spiele, die mit unter 20 FPS laufen.
Eine genauere Betrachtung findet sich in einem extra Thread:
platzhalter
Hier geht es um die Testszene und diese gefällt mir ganz gut. Ich benutze zwar eine recht komplizierte Route und wenn es Ausreißer gibt, sind diese zufällig verteilt. Daher ist die Szene recht lang um diese Ausreißer zuverlässiger einzufangen. Auch laufe ich recht weit weg, was dafür sorgt, das man bei der nächsten Runde andere NPCs sieht. Wie schon an anderer Stelle beschrieben laufe ich eine Runde und starte die Messungen hintereinander anstatt neu zu laden. Das hat den Grund, dass man bei nach jedem neu laden erstmal vermehrt Schwankungen hat, die ich vermeiden möchte.
Die zweite Szene ist grob die Testsequenz von CB, die ich nachgestellt habe. Für einen Grafikkartentest sicherlich OK aber als CPU Test halte ich sie für ungeeignet.
Vergleicht man die CB Szene mit den ersten 25s der Novigrad-Szene unter Windows 7 zeigt sich wie wenig die CPU im Vergleich gefordert wird.
Zu*ge*ge*be*ner*ma*ßen relativieren sich die Unterschiede wenn wir auf Windows 10 wechseln.
Aber zumindest zeigen sich in Novigrad belastbare Unterschiede zwischen den CPUs und wenn man sich z.B. die Tests von DigitalFoundry anguckt, sieht man, dass mit einer besseren Grafikkarte sogar Unterschiede in den avg FPS relevant werden.
Das war es mit den dokumentierten Testszenen, die ich untersucht habe.
Ich hatte noch eine ganze Reihe Spiele mehr getestet, aber viele waren unzuverlässig, uninteressant, haben die CPU nicht belastet oder waren einfach zu viel Arbeit.
Hier ein paar Gedanken zu den verworfenen Tests:
AC3 läuft zu gut und man muss erst das FPS Cap entfernen, Anno1404 hätte ich gerne getestet aber es war sehr schwer zu reproduzieren
Dirt Rally hätte ich gerne getestet aber der integrierten Benchmark nutzt teilweise andere Kamerapositionen und bringt dann systematische Fehler in die Messungen. Leider fahre ich nicht so konsistent um eine bessere Reproduzierbarkeit zu schaffen. Ich habe trotzdem einige Tests dazu gemacht, die ich eventuell extra behandeln werde.
Heroes V hat bei mir komisches Stottern ohne ersichtlichen Grund...so wie massive Nachladeruckler. Raceroom war wie Dirt Rally.
Für Rise of the Tomb Raider bräuchte ich ein gutes savegame.
Overwatch läuft zu gut und ich hatte es nur am kostenlosen Wochenende getestet.
For Honor läuft zu gut und ich hatte es nur am kostenlosen Wochenende getestet.
Rainbow Six: siege hatte ich nur am kostenlosen Wochenende getestet. Aus Zeitgründen habe ich nur den Benchmark laufen lassen und das Tutorial gespielt. Mein Ryzen 8 Kerner hatte keine Probleme die Vega64 zu befeuern. Die CPU Auslastung war aber sehr hoch und mit dem i5 hätte ich vermutlich Probleme bekommen.
Dirt Rally hätte ich gerne getestet aber der integrierten Benchmark nutzt teilweise andere Kamerapositionen und bringt dann systematische Fehler in die Messungen. Leider fahre ich nicht so konsistent um eine bessere Reproduzierbarkeit zu schaffen. Ich habe trotzdem einige Tests dazu gemacht, die ich eventuell extra behandeln werde.
Heroes V hat bei mir komisches Stottern ohne ersichtlichen Grund...so wie massive Nachladeruckler. Raceroom war wie Dirt Rally.
Für Rise of the Tomb Raider bräuchte ich ein gutes savegame.
Overwatch läuft zu gut und ich hatte es nur am kostenlosen Wochenende getestet.
For Honor läuft zu gut und ich hatte es nur am kostenlosen Wochenende getestet.
Rainbow Six: siege hatte ich nur am kostenlosen Wochenende getestet. Aus Zeitgründen habe ich nur den Benchmark laufen lassen und das Tutorial gespielt. Mein Ryzen 8 Kerner hatte keine Probleme die Vega64 zu befeuern. Die CPU Auslastung war aber sehr hoch und mit dem i5 hätte ich vermutlich Probleme bekommen.
Zufrieden bin ich bei meinen eigenen Testszenen nur mit Heroes of the Storm, Prison Archiect, Starcraft 2, und Witcher 3.
Mit Einschränkungen City Skylines, Mafia 3, Prey, RomeTW und Witcher1 und 2.
Ich werde die neuen Testszenen nach und nach einfügen und würde mich über Fragen und Anregungen, sowie konstruktive Kritik freuen
.
Zuletzt bearbeitet:
