Nous republions aujourd'hui un article écrit du temps de Zeden V3. A l'époque existaient des sites dédiés à certains jeux, notamment Unreal Tournament 2004 et comportaient quelques tests intéressants. Malheureusement, ses articles n'étaient plus accessibles depuis le passage à la version actuelle du site. Nous commençons à réparer cette erreur. L'article suvant vous expliquera en détails la méthode à suivre afin de réaliser un benchmark sous Unreal Tournament 2004.

Introduction

Il est d'usage de se renseigner avant d'acheter quoi que ce soit, et il en est de même pour le matériel informatique. Certaines cartes graphiques ou certains processeurs, sont à des prix tels qu'il vaut mieux être sûr de soi avant de les commander.

Pour aider l'internaute à se décider en toute connaissance de cause, de nombreux sites proposent des tests de ces matériels en se concentrant sur les performances obtenues.
Ces tests sont réalisés avec des outils qui peuvent être spécifiques, comme dans le cas des benchmarks synthétiques (ex : Sandra) ou bien avec des logiciels réels, par exemple des jeux.

Unreal Tournament 2004 étant largement employé à cet effet sur bon nombre de sites web, l'objectif de ce document est de vous apprendre à faire vous-même vos propres tests. Cela vous permettra de mesurer la performance de votre configuration et de ses variantes.

Dans un premier temps sera abordée une description générale des performances d'un jeu, puis viendra la méthode proprement dite, expliquée pas à pas.

Généralités

Commençons par une définition. Le nombre d'images, ou de "frames" pour parler anglais, est l'élément le plus important quand on évalue la performance d'une machine destinée à jouer. On parle aussi de framerate.

Pour faire simple : plus le système informatique est puissant et plus il y a de frames par seconde, plus le jeu est jouable.

On peut être tenté de dire "De toute façon, au delà de 24 fps, l’œil ne fait plus la différence."
ou bien "Le cinéma tourne a 24 FPS, donc un jeu, à 24 FPS, c'est suffisant." Moi aussi, chers lecteurs, je le croyais avant de commencer à écrire cet article. Et en me renseignant j'ai appris qu'il fallait tordre le coupa quelques idées reçues, toutes fausses, notamment en lisant cet article, de chez Nofrag.

Non, l’œil n'est pas "limité" à 24 images par secondes. Des expériences militaires ont montré qu'un pilote pouvait reconnaître un avion, alors que l'image ne lui était présentée 1/220^e de seconde. 1/220^e de seconde pour une image correspond à 220 image/seconde, ce qui est bien supérieur aux 24 images/seconde habituellement énoncé.

Et si le cinéma utilise effectivement 24 images par secondes, ce n'est pas parce que cela permet de rendre l'effet de mouvement, mais parce que cela permet de mettre la bande son. 18 images seraient en fait suffisantes, car c'est parce que les images sont FLOUES qu'il y a impression de mouvement. Tout simplement. Faites un arrêt sur l’image d'un film où il y a du mouvement. L'image ne sera jamais nette à l'endroit où il y a des éléments en mouvement, et plus ils iront vite, et plus cela sera flou !

Un exemple : voici une image tirée de Matrix (capture matérielle du DVD).


Notez comme le décor est net, comme les personnages le sont moins et comme leurs membres ne le sont pas du tout. Si il n'y avait pas ce flou, il y aurait des saccades, exactement comme quand un jeu "rame". Ce flou, c'est le "Motion blur", le flou de mouvement. On l'utilise pour donner l'impression de mouvement et de vitesse. On trouve aussi cet effet dans les outils de retouche d'image.

En conclusion de ces paragraphes: chaque frame compte, même si bien sûr quand on atteint des chiffres élévés, autour de 40-50, cela se sent nettement moins. D'ailleurs, UT considère qu'en dessous de 40 FPS, le jeu n'est pas complètement fluide.

Pour dresser une liste des éléments matériels et logiciels ayant un impact sur le nombre de FPS, il suffit de s'intéresser à tous les éléments qui participent à la construction d'une image. S'il y a 20 ans cette liste était très restreinte, celle-ci devient de plus en plus longue au fur et à mesure des avancées techniques.
On peut quand même citer les principaux facteurs:

• Matériel
  • Processeur
  • Chipset
  • Mémoire
  • Carte graphique

• Logiciel
  • Système d'exploitation
  • Drivers
  • Bibliothèque de l'API graphique
  • Le jeu lui même

N'oublions pas non plus que le nombre de FPS (frame par seconde) va de paire avec un autre élément, beaucoup plus subjectif : la qualité d'image.
Plus une image est de haute qualité, plus il y a de détails affichés, et plus il faut de temps au système pour la calculer, ce qui évidemment a un impact négatif sur le framerate. Résolution, Filtrage Anisotrope, anticrénelage, et réglages graphiques, entre autres, sont donc des éléments à surveiller de près.

Maintenant que nous savons ce que nous allons mesurer (les FPS) et les
facteurs influents, arrêtons-nous sur ce qu'est une mesure.

Mesure, vous avez dit mesure ?

Nous souhaitons déterminer la performance d'une configuration matérielle quelconque. Pour ce faire, nous allons "mesurer" le nombre de FPS. La mesure est une science à part entière, avec son lot de techniques et de termes barbares, qui ont des définitions très précises. Deux de ces termes sont "répétabilité" et "reproductibilité".

Pour qu'une mesure soit jugée correcte, il faut, parmi d'autres éléments, qu'elle soit répétable et reproductible.

• Répétable signifie que lorsqu'on lance un bench, plusieurs fois de suite dans les mêmes conditions, on doit trouver un résultat similaire à chaque fois. Si je lance un benchmark sur ma machine et que j'obtiens 50 fps de moyenne, en lançant 10 fois le benchmark, je dois toujours avoir 50 fps.
• Reproductible signifie qu'avec la liste exacte de tous les paramètres, on peut reproduire le même résultat. Si avec ma machine, je fais 50 FPS, une machine en tout point équivalente, dans les même conditions, doit faire un score très proche.

On voit donc, grâce à ces définitions, que les conditions de tests sont fondamentales pour faire des benchmarks significatifs. Sur la page précédente, je donne une petite liste des facteurs influents sur le nombre de FPS. Lorsqu'on annonce un score obtenu dans un benchmark, il faut l'accompagner de la liste complète des paramètres employés. Cela peut s'avérer fastidieux, c'est vrai. Mais on peut faire dire tout et n'importe quoi à des chiffres quand ils sont placés en dehors de leur contexte.

Gardons ces considérations en tête, mais intéressons-nous maintenant au plus important, la méthodologie.

Méthodologie de test

Comme énoncé précédemment, un benchmark c'est un ensemble de paramètres (puissance de processeur, version de drivers de la carte vidéo, map du jeu...) et un score. L'utilisateur, vous, fixez ces paramètres et UT, via des outils intégrés, vous fournit le score correspondant.

On pourrait imaginer utiliser un logiciel indiquant en temps réel le nombre de FPS, par exemple FRAPS. Il suffit de jouer, et on voit le nombre de FPS apparaître. Le problème, c'est qu'une partie ne ressemble jamais à une autre. Il n'y a ici ni répétabilité, et encore moins de reproductibilité. Oublions la reproductibilité pour l'instant, et concentrons-nous
sur la répétabilité. L'objectif est, dans un premier temps, de vous permettre de comparer votre machine avec plusieurs réglages différents et voir leurs impacts, et ainsi déterminer entre autres dans quelle résolution et avec quels réglages vous pouvez jouer confortablement.

UT, et bon nombre de jeux, permettent l'enregistrement de "démo", c'est à dire d’une partie telle que le joueur la voyait depuis son écran lorsqu’il l’a jouée. Cela a 2 usages. D'une part, pour les bons joueurs, de montrer leur talent et d'étudier la technique des autres joueurs, mais cela permet aussi de faire de bons benchmarks. Pourquoi ? Tout simplement parce qu'à chaque test, la démo est identique à 100%.
Même configuration matérielle, mêmes réglages, même démo, et on a un benchmark avec une très bonne répétabilité !

Commençons par l'enregistrement d'une demo :

• 1) Lancer le jeu.
• 2) Lancer une partie solo dans n'importe quel mode de jeu, avec quelques bots
  et surtout, indiquer une petite limite de temps, 3 minutes par exemple.
• 3) Ouvrir la console (penser à attribuer une touche pour cela)
• 4) Taper dans la console demorec nomdelademo
• 5) Fermer la console
• 5) Jouer normalement
• 6) Lorsque la partie est finie (au bout de 3 minutes), réouvrir la console
• 7) Taper stopdemo

UT a placé le fichier de démo dans un nouveau répertoire, simplement nommé Demos, dans à la racine du répertoire du jeu. Les démos Unreal Tournament ont une extension .demo4, indiquant que c'est une démo réalisée avec la version 2004 du jeu.
Vous pouvez vous assurer du fonctionnement de la démo en la jouant. Pour ce faire, rien de plus simple. Depuis le menu principal du jeu, vous allez dans "Communauté", et là, en haut, un onglet "demos" est apparu. Vous pourrez ainsi rejouer votre demo ou la transformer en vidéo au format AVI. Je dis "transformer", car à la base une démo n'est pas un film. C'est d'ailleurs pour ça que c'est si long à charger. Les fichiers *.demo4 contiennent en fait tous les évènements s'étant produits lors d'une partie, comme les mouvements du joueur, les mouvements des bots, les frags, etc.

Voyons maintenant comment utiliser cette démo avec l'outil de benchmark intégré
Maintenant que nous avons créé une démo, nous allons enfin pouvoir nous en servir. Vous avez peut-être remarqué la présence d'un répertoire "Benchmark" dans le dossier du jeu. Dans ce répertoire sont présents 2 sous répertoire importants, « stuff » et « results ». Dans "Stuff", nous allons placer nos fichiers correspondants aux benchmarks que nous souhaitons réaliser. Et dans
"Results" apparaîtront des fichiers texte comportant le résultat. Magique, non ?

Tout d'abord, nous allons créer un fichier .txt indiquant comment la démo doit être jouée. Pour ce faire créer un fichier texte, dans le dossier "Stuff", et placez-y les lignes suivantes :

demoplay nomdelademo?timedemo

stat fps

La première ligne indique qu'il faut jouer la demo en mode "timedemo", c'est a dire le plus rapidement possible, sans respecter la durée de la démo initiale. La deuxième ligne indique à UT de montrer les FPS en surimpression lors de la démo, afin de donner un aperçu à l'utilisateur.

Pour chaque fichier de démo que vous voulez utiliser pour un benchmark, il vous faudra faire ce fichier texte.

Maintenant nous allons créer un fichier de benchmark. C'est en fait un fichier bat qui lance
UT en mode benchmark et utilisant la démo que nous avons préalablement créée.

Créer un fichier nomdelademo.bat contenant les lignes suivantes :

cd..
cd..
cd System
UT2004.exe -exitafterdemo -benchmark -ini=UT2004.ini -exec=..\benchmark\stuff\pierrot1.txt
cd ..
cd Benchmark\Stuff

Examinons la ligne principale :

UT2004.exe -exitafterdemo -benchmark -ini=UT2004.ini -exec=..\benchmark\stuff\nomdelademo.txt

On lance Unreal Tournament 2004, en mode benchmark (-benchmark), qui va se fermer automatiquement après avoir benchmarké la demo (-exitafterdemo), qui va se lancer en utilisant les paramètres du fichier ini classique (-ini=UT2004.ini) et qui va lancer le fichier txt contenant les informations relatives à la démo (-exec=..\benchmark\stuff\nomdelademo.txt).
Il existe bon nombre d'autres paramètres, nous y reviendront un peu plus tard.

Nous avons préparé notre premier benchmark. Lançons-le ! Lancez le fichier .bat, et si tout se passe bien, vous verrez UT s’exécuter puis charger la démo. Ensuite, vous verrez la démo défiler au maximum de la vitesse dont votre système est capable, dans la résolution configurée dans UT et avec les réglages de qualité d'images d'UT. Finalement, UT se fermera automatiquement. Vous n'avez plus alors qu'à aller dans le répertoire "\Benchmark\Results", et vous verrez un fichier .log avec un contenu similaire à celui-ci :

UT2004 Build UT2004_Build_[2004-03-03_02.42]
Windows XP 5.1 (Build: 2600)
AuthenticAMD Unknown processor @ 2413 MHz with 1023MB RAM
RADEON 9700 PRO (Omega 2.5.76) (6476)
-exitafterdemo -benchmark -ini=UT2004.ini -exec=..\benchmark\stuff\pierrot1.txt

55.207676 fps rand[15429]

Ce fichier résultat reprend les éléments fondamentaux des paramètres du test :
Version d'UT, version de Windows (ou de MaCOS ou de Linux), processeur, carte vidéo, mémoire, ainsi que la ligne de commande du benchmark. Il contient aussi le plus important : le score ! Dans le cas de ce test : 55.20 fps.
Ce nombre représente le framerate moyen obtenu tout au long de la démo.

Si vous lancez le même fichier .bat plusieurs fois de suite, vous verrez que le score varie, et que cette variation peut facilement être de l'ordre de plus ou moins une ou 2 frames. Cet écart, qu'on peut remarquer d'un benchmark à l'autre, alors que les conditions de tests sont rigoureusement identiques, est normal. C'est l'erreur de mesure, liée notamment à tous ce qui se passe dans un PC et qui ne peut pas être contrôlé.

Autre remarque, vous avez peut-être constaté que, normalement, le compteur de frame qui est affiché pendant un benchmark est de couleur verte, et que parfois il vire au jaune, au violet ou au rouge. En fait, le compteur indique par ces changements que des seuils ont été franchis. Au delà de 40 FPS, le compteur est vert. Entre 30 et 40, il est jaune. Et en-dessous de 30, il passe au violet, pour virer au rouge en dessous de 20 ! Cet indicateur quadricolore permet de savoir si le niveau de performance est suffisant ou non pour jouer avec les paramètres graphiques choisis.

Nous avons vu comment benchmarker de manière simple avec UT2004. On peut aller encore plus loin, notamment en améliorant le fichier .bat.

Approfondissement

Nous venons d'aborder les benchmarks simples. On enregistre une démo, on la prépare pour être benchée (le fichier .txt) puis on prépare le benchmark en lui-même (le fichier bat). On lance finalement tout ça, en prenant les réglages graphiques par défaut et on obtient le résultat. Si on veut par exemple voir l'impact de la résolution, il faut changer dans UT, entre 2 lancements du bat, la résolution, idem pour les options graphiques.

L'outil de benchmark permet en fait de spécifier toutes les options graphiques, directement ou indirectement, dans le fichier .bat. Et, comme c'est un fichier .bat, on peut lancer autant de benchmark qu'on veut, les uns à la suite des autres. Il suffit de passer un peu de temps à créer ce fichier, et vous n'avez plus qu'à attendre les résultats.

Voici 2 options sympathiques, qui peuvent être ajoutées dans le fichier .bat :

• -nosound : supprime le son lors de la lecture de la démo.
• -largeur*hauteur : joue la démo en résolution hauteur*largeur. Par exemple l'option -1024*768 joue la démo en 1024*768.

En ce qui concerne les réglages graphiques du jeu, en dehors
de la résolution, il faut pour cela modifier le fichier .bat, au niveau indiqué en gras dans la ligne suivante :
UT2004.exe -exitafterdemo -benchmark -ini=UT2004.ini -exec=..\benchmark\stuff\nomdelademo.txt

Faites une copie de UT2004.ini et ouvrez-le. Vous devrez trouver, entre autres, une section "[WinDrv.WindowClient]"
qui contient les lignes suivantes :

[WinDrv.WindowsClient]
WindowedViewportX=640
WindowedViewportY=480
FullscreenViewportX=1024
FullscreenViewportY=768
MenuViewportX=640
MenuViewportY=480
Brightness=0.800000
Contrast=0.700000
Gamma=0.800000
UseJoystick=False
CaptureMouse=True
StartupFullscreen=True
ScreenFlashes=True
NoLighting=False
MinDesiredFrameRate=35.000000
AnimMeshDynamicLOD=0.000000
Decals=True
Coronas=True
DecoLayers=True
Projectors=True
NoDynamicLights=False
ReportDynamicUploads=False
TextureDetailInterface=Normal
TextureDetailTerrain=Higher
TextureDetailWeaponSkin=Higher
TextureDetailPlayerSkin=Higher
TextureDetailWorld=Higher
TextureDetailRenderMap=Higher
TextureDetailLightmap=Higher
NoFractalAnim=False
ScaleHUDX=0.000000
MouseXMultiplier=1.000000
MouseYMultiplier=1.000000
UseSpeechRecognition=True
WeatherEffects=True
DrawDistanceLOD=1.000000

Les lignes en gras correspondent aux 15 options disponibles dans la page "options graphiques" du jeu et sont donc les lignes qui nous intéressent. Il peux être intéressant de faire 3 fichiers ini différentiels, avec des valeurs différentes pour les lignes en gras. Le but est de faire un fichier avec des réglages "minimums", des réglages "moyens" et des réglages "élevés".

Pour ce faire, allez dans le répertoire "\System" et faites 3 copies du fichier UT2004.ini, dans le même répertoire. Nommez les copies "minimum.ini", "medium.ini" et "maximum.ini" et modifiez-les tel qu'indiqué :
Mininum.ini

[WinDrv.WindowsClient]
Decals=False
Coronas=False
DecoLayers=False
Projectors=False
NoDynamicLights=True
ReportDynamicUploads=False
TextureDetailInterface=Normal
TextureDetailTerrain=UltraLow
TextureDetailWeaponSkin=UltraLow
TextureDetailPlayerSkin=UltraLow
TextureDetailWorld=UltraLow
TextureDetailRenderMap=UltraLow
TextureDetailLightmap=UltraLow
NoFractalAnim=False
WeatherEffects=False

Nb : il faut laisser les autres lignes de la section [WinDrv.WindowsClient] inchangées.

Medium.ini

Decals=True
Coronas=True
DecoLayers=False
Projectors=True
NoDynamicLights=True
ReportDynamicUploads=False
TextureDetailInterface=Normal
TextureDetailTerrain=Normal
TextureDetailWeaponSkin=Normal
TextureDetailPlayerSkin=Normal
TextureDetailWorld=Normal
TextureDetailRenderMap=Normal
TextureDetailLightmap=Normal
NoFractalAnim=False
UseSpeechRecognition=True
WeatherEffects=True

Nb : il faut laisser les autres lignes de la section [WinDrv.WindowsClient] inchangées.

Maximum.ini

[WinDrv.WindowsClient]
Decals=True
Coronas=True
DecoLayers=True
Projectors=True
NoDynamicLights=False
ReportDynamicUploads=False
TextureDetailInterface=Normal
TextureDetailTerrain=UltraHigh
TextureDetailWeaponSkin=UltraHigh
TextureDetailPlayerSkin=UltraHigh
TextureDetailWorld=UltraHigh
TextureDetailRenderMap=UltraHigh
TextureDetailLightmap=UltraHigh
NoFractalAnim=False
WeatherEffects=True

Nb : il faut laisser les autres lignes de la section [WinDrv.WindowsClient] inchangées.

Un point important à préciser : Les 2 seules options graphiques qui ne peuvent pas être indiquées dans le .bat sont l'Anti Aliasing (AA) ou anticrénelage et l'Anisotropic Filtering (AF) ou filtrage anisotrope. Ces 2 paramètres doivent être réglés dans le panneau de contrôle des drivers de votre carte graphique, car UT n'intègre aucun moyen de les régler.

On peut donc imaginer, toujours grâce à un fichier .bat, tester UT dans 3 résolutions différentes
avec 3 niveaux de détails différents, afin de déterminer quelles est la combinaison la plus efficace pour votre machine.

Pour ce faire, créer le fichier .bat suivant, toujours dans le dossier "\Benchmark\Stuff".

cd..
cd..
cd System
UT2004.exe -exitafterdemo -benchmark -800*600 -ini=minimum.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1024*768 -ini=minimum.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1280*1024 -ini=minimum.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -800*600 -ini=medium.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1024*768 -ini=medium.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1280*1024 -ini=medium.ini -exec=..\benchmark\stuff\nomdelademotxt
UT2004.exe -exitaafterdemo -benchmark -800*600 -ini=maximum.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1024*768 -ini=maximum.ini -exec=..\benchmark\stuff\nomdelademo.txt
UT2004.exe -exitafterdemo -benchmark -1280*1024 -ini=maximum.ini -exec=..\benchmark\stuff\nomdelademo.txt
cd ..
cd Benchmark\Stuff

Évidemment, ce n'est qu'un exemple. Il peut être personnalisé. N'oubliez pas de lancer plusieurs fois votre fichier .bat, pour vérifier la répétabilité.

Conclusion

On a vu aussi qu'entre faire un benchmark et faire
un bon benchmark pertinent et significatif, il y a une grande différence.
On peut facilement faire dire n'importe quoi aux chiffres quand ils ne sont pas placés dans leur contexte, et les fabricants, malheureusement, n'hésitent pas à le faire.

UT2004 se révèle être un excellent outil de bench, grâce aux fonctions intégrées liées aux démos et aux mesures de framerate. La partie "tutorial" fournie va vous permettre de faire comme sur les sites web, et vous serrez en mesure de dire, sans que cela ne soit qu'une impression, que c'est plus fluide dans telle résolution avec tels réglages plutôt que dans telle autres avec des réglages différents.

Mais cet article n'en est qu'à sa première partie. Pour le moment, seuls le "pourquoi" et le "comment" des benchmarks sous UT ont été abordés. Une 2^e partie est en préparation. Elle aura pour but, au travers d'un certains nombre de benchmark réalisés sur un certain nombre de machines différentes, de tirer des tendances sur l'impact des performances des différents facteurs.

Bonne lecture, et bons benchs ! N'hésitez pas à me contacter si vous avez des questions, des remarques ou des précisions à apporter.

Article rédigé et mis en page : Xpierrot
Validation du tuto : VooDooS
Remerciements à Zork pour la partie Généralités