Unreal Tournament 2003 Demo Grafikchip-Shootout

15. September 2002 / von Leonidas / Seite 4 von 4

Fazit

Die ermittelten Benchmark-Werte zeigen deutlich, daß ohne anisotropen Filter und ohne Anti-Aliasing Unreal Tournament 2003 einen gesunden Mix an CPU-Leistung und Grafikkarten-Power benötigt, um auf Touren zu kommen. Mit einer großen CPU sind dann als Grafikchips GeForce 3/4 und auch die Radeon 8500 zu empfehlen. Wer rein auf den anisotropen Filter setzt, ist mit der Radeon 8500 am besten beraten, da diese jenen Filter "for free" zum Einsatz bringen kann. Unter Anti-Aliasing führen dagegen die GeForce4 Ti Chips klar das Feld an.

Unter dem Einsatz des "Super-Settings" 8x anisotropen Filter und 4x Anti-Aliasing kommt dagegen keiner der getesteten Grafikchips auf vernünftige Frameraten. Einzig allein die Chips der nächsten Generation um ATi Radeon 9700 und nVidia NV30 scheinen für dieses Setting unter Unreal Tournament 2003 geeignet. Unter dem abgeschwächten Kombi-Setting 2x anistropen Filter und 2x Anti-Aliasing erreichen dagegen GeForce4 Ti und Radeon 8500 gute und spielbare Resultate.

Ein Wort noch zur hier nicht mitgetesteten Radeon 9700 Pro: Im normalen Einsatz ohne anisotropen Filter und ohne Anti-Aliasing wird sie eine wirklich große CPU benötigen, um sich von der GeForce4 Ti4600 absetzen zu können. Möglicherweise reichen hierfür nicht einmal die stärksten verfügbaren CPUs um Pentium 4 Northwood 2.8 GHz und Athlon XP 2600+ aus, es könnte selbst bei diesen zu einem Patt zwischen GeForce4 Ti4600 und Radeon 9700 kommen. Bei allen Settings mit anisotropen Filter und mit Anti-Aliasing wird die Radeon 9700 die GeForce4 Ti4600 bzw. die Radeon 8500 allerdings klar abhängen - dafür kostet sie schließlich auch mehr :-).

Unreal Tournament 2003 hat sich zudem als erstklassiger Benchmark präsentieren können. Es gibt neben einer guten CPU-Limitierung auch eine hohe Grafikkarten-Limitierung, so daß dieser Benchmark auch die Hardware des Jahres 2003 noch ausreichend stark fordern wird. Zudem ergaben sich nur geringe Meßtoleranzen im Bereich von im Normalfall nur 0,5 Prozent, im höchsten von uns festgestellten Fall auch nur 2 Prozent. Auch aufgrund dieser Zuverlässigkeit der Ergebnisse kann der Einsatz der Demo von Unreal Tournament 2003 - und später dann das Spiel - als Benchmark nur empfohlen werden.

Abschließend wollen wir noch einen Gedankengang in die Runde werfen: Unreal Tournament 2003 bietet in etwa diese Grafik, welche uns anno 1999 beim Start der originalen GeForce versprochen wurde. Das Spiel setzt schließlich noch nicht auf DirectX8 Vertex und Pixel Shader, sondern rein auf die festverdrahteten T&L-Einheiten von DirectX7, die gebotene Grafik ähnelt zudem dem Marketing-Material von 1999 ziemlich stark. Irritierend ist nun nicht nur, daß es drei Jahre gebraucht hat, bis diese beim Start der GeForce versprochene Grafik erreicht wurde, sondern auch, daß der damals mit einer solchen Grafikpracht beworbene Chip für das heutige Unreal Tournament 2003 im Prinzip schon zu langsam ist ...

Nachträge

wichtigste Tips & Tricks:

Die Konsole liegt auf deutschen Systemen auf der ö-Taste.
Mit dem Konsolen-Kommando "stat fps" wird ein Frame-Counter eingebunden. Dessen average-Wert scheint allerdings nur der Durchschnittswert der letzten Sekunden zu sein, also kein allgemeiner Durchschnitt.
Mit dem Konsolen-Kommando "preferences" kommt man in die erweiterten Optionen, in welchen man fast alles einstellen kann, was in der "UT2003.ini" und der "User.ini" steht.
Um auf das höchste Gore-Level zu kommen, ändert man in der "UT2003.ini" die Zeile "Language=det" auf "Language=eng" oder "Language=int". Danach ändert man in derselben Datei noch die Zeile "GoreLevel=2" auf "GoreLevel=0".
Um in den OpenGL-Modus zu gelangen, setzt man in der "UT2003.ini" vor der Zeile "RenderDevice=D3DDrv.D3DRenderDevice" ein Semikolon ; ein und löscht das vorhandene Semikolon vor der Zeile "RenderDevice=OpenGLDrv.OpenGLRenderDevice" (und genauso macht man das ganze dann auch wieder rückgängig).
Um mit dem Rocketlauncher anstatt mit normalen Rocketlauncher-Granaten mit Redeemer-Granaten zu schiessen, fügt man in der "User.ini" bei einer beliebigen freien Taste (beispielsweise "I="), den Befehl "set XWeapons.Rocketlauncher FireModeClass class'XWeapons.RedeemerFire' | set XWeapons.RedeemerFire AmmoClass Class'XWeapons.RocketAmmo'" direkt hinzu (ohne Leerzeichen direkt in diese Zeile). Danach drückt man im Spiel, bevor man den Rocketlauncher aufnimmt, diese Taste und hat die Redeemer-Granaten. Achtung! Erstens schießen dann auch die Bots mit diesen und zweitens haben diese einen sehr großen Explosionsradius. Aber sehr hübsch anzusehen :-).
Screenshots werden im übrigen mit der F9-Taste erzeugt und liegen dann mit durchnummerierten Dateinamen und im BMP-Format im System-Verzeichnis des Spiels.

Linkliste:

Nachtrag vom 16. September 2002:

Auch die ComputerBase und G256 haben sich mit Unreal Tournament 2003 als Benchmark beschäftigt und können eine Vielzahl an Benchmark-Resultaten präsentieren. Diese Zahlen stammen jedoch in beiden Fällen nicht vom selben Testsystem, sondern man hat vielmehr die Ergebnisse, die in den jeweiligen Foren gepostet wurden, zu einer Tabelle zusammengefaßt. Dies mag nicht unbedingt die allerbeste Vergleichbarkeit garantieren, da jedes PC-System nun einmal etwas anders konfiguriert ist, aber es ermöglicht eben auch den Überblick über die UT2003-Ergebnisse einer großen Zahl von teilweise gebräuchlichen und teilweise kuriosen Systeme.

Beide Results-Übersichten beinhalten neben dem von uns genutzten Botmatch-Vergleich auch die Werte der FlyBy-Sequenzen. Wir haben die FlyBy-Sequenzen bewußt nicht mit in unseren Test aufgenommen, auch wenn dann einige Ergebnisse unseres Tests klar CPU-limitiert sind. Der Grund hierfür sind die unrealistisch hohen Frameraten des FlyBy-Tests, welcher in keinster Form den in einem realen Spiel erreichten Frameraten entsprechen. Man kann zwar damit argumentieren, daß die FlyBy´s die Grafikkarten-Leistung besser herausstellen - doch war uns in unserem Test nicht in erster Linie daran gelegen. In erster Linie ging es bei unserem Test um die real in der Demo von Unreal Tournament 2003 erreichbare Leistung, aus dieser Sicht sind die Botmatches die einzige sinnvolle Wahl.

Nachtrag vom 17. September 2002:

Mit der Zeit haben sich nun einige Erkenntnisse zum Benchmarking unter Unreal Tournament 2003 angesammelt. So muß zu allererst einmal klar gestellt werden, daß Benchmarks mit der "Benchmark.exe" prinzipiell mit der "MaxDetail.ini" im Benchmark-Verzeichnis gefahren werden, während Benchmarks über die Batch-Files im Benchmark-Verzeichnis die normale "UT2003.ini" aus dem System-Verzeichnis nutzen. Damit geraten die Benchmarks über die Batchfiles natürlich immer in Gefahr, daß mit veränderten User-Einstellungen anstatt mit den einheitlichen Settings der "MaxDetail.ini" gebencht wird.

Desweiteren konnte man über die gesammelten Benchmarks in unserem Forum (Übersichtstabellen) feststellen, daß Software Audio erstaunlicherweise um 5 bis 10 Prozent schneller ist als Hardware Audio, wobei die Mindestframeraten bei Hardware Audio teilweise wieder höher liegen (die Mindestframeraten sind allerdings nur der Wert eines einzelnen Frames). Hochinteressant ist im übrigen die Aussage von Epic, nach welcher im Botmatch die künstliche Intelligenz (KI) der Bots mitberechnet wird. Alle uns bisher bekannten benchmarkfähigen Spiele speichern in ihren Demo-Dateien alle Entscheidungen der KI, so daß der Demo-Ablauf immer 100%ig identisch ist, dafür aber in einem Demo-Ablauf auch die CPU-Berechnungszeit für die KI komplett fehlt.

Bei UT2003 war es nun Epic extra daran gelegen, diese Intelligenz-Berechnungen auch mit in den Benchmark zu bringen, da so realistische Resultate - bezüglich von Botmatches - erzielt werden. Unter dem selben Link findet sich auch ein weiteres Epic-Statement, welches noch einmal klärt, ob Unreal Tournament 2003 nun Vertex und Pixel Shader nutzt oder nicht. Danach muß man unterteilen zwischen "nutzen" und "ausnutzen". Genutzt werden bei jenen Grafikchips, welche nicht mehr über eine DirectX7 T&L Einheit verfügen, natürlich der DirectX8 Vertex Shader, welcher dann dieselbe Funkionalität übernimmt. Und genutzt wird auf DirectX8-Grafikkarten der DirectX8 Pixel Shader zu Darstellung von CubeMapping (damit werden Rundum-Spiegelungen erzeugt).

Dies erfolgt allerdings beides nur zur Beschleunigung, denn auf DirectX7-Grafikkarten steht dieselbe Funkionalität nur eben im DirectX7-Gewand zur Verfügung. Das heißt, UT2003 nutzt zwar DirectX8-Einheiten auf den entsprechenden Grafikkarten, stellt aber keine DirectX8-Effekte, sondern auf allen Grafikkarten einheitlich DirectX7-Effekte dar. Auf DirectX8-Effekte war das Spiel sowieso noch nie geplant, da es für seinen Zweck als schneller EgoShooter vernünftige Frameraten bieten können muß. Mit Unreal II wird Epic dann auch DirectX8-Effekte nutzen, dafür werden die Hardware-Anforderungen dieses Spiels natürlich gleich noch einmal höher werden.

Und letztlich haben wir noch den OpenGL-Modus einem kleinem Test unterzogen und konnten in diesem kaum Unterschiede zum standardmäßigen Direct3D-Modus feststellen. Den OpenGL-Modus ist leider nicht mehr offiziell supportet, dementsprechend kommt man an diesen über den Befehl "preferences" in der UT2003-Konsole (auf deutschen Systemen auf der ö-Taste) auch nicht mehr heran. Um zu diesem gelangen, muß man manuell in der "UT2003.ini" vor der Zeile "RenderDevice=D3DDrv.D3DRenderDevice" ein Semikolon ; einfügen und das vorhandene Semikolon vor der Zeile "RenderDevice=OpenGLDrv.OpenGLRenderDevice" löschen (und genauso macht man das ganze dann auch wieder rückgängig).

Die Bildqualität war auf den ersten Blick diesselbe, die Frameraten lagen geringfügig niedriger (System I mit P3C/1.0 + GeForce4 Ti4600: 30,9 zu 30,3 fps, System II mit P4W/1.98 + Radeon 8500: 44,6 zu 42,8 fps im "Benchmark.exe"-Botmatch) und auch während des Spielens unter OpenGL gab es keinerlei Probleme zu verzeichnen. Dies ist insofern beachtlich, als in den OpenGL-Modus von UT2003 wohl bei weitem nicht so viel Arbeit wie in den Direct3D-Modus gesteckt wurde. Aufgrund des inoffiziellen Charakters kann natürlich nicht garantieren werden, daß OpenGL bei allen Systemen so problemlos läuft wie auf unseren zwei Testsystemen.