Cela fait maintenant une semaine que Quake 4 est disponible et que pas mal de joueurs du troisième épisode regardent ce qu’il a dans le ventre. Alors bon, la découverte des jolis graphismes en 1600×1200 avec anti-aliasing et filtrage anisotrope ça va cinq minutes, mais il faut bien passer aux choses sérieuses un jour ou l’autre.
Ce petit guide vous présente quelques-unes des principales commandes utilisées pour configurer l’aspect graphique du jeu, afin de gagner quelques FPS et surtout de la lisibilité. Il n’a pas la prétention d’être exhaustif mais de donner un petit aperçu de ce qu’il est possible de réaliser avec le nouveau moteur.
[–SUITE–]Quelques généralités sur les fichiers de configurations dans Quake 4
Le principal fichier de configuration est le quake4config.cfg qui se trouve dans le répertoire q4base/ du jeu. A celui-ci vient s’ajouter un second fichier, l’autoexec.cfg, situé au même endroit, qui peut contenir d’autres informations. A eux deux, ils comprennent toutes les données nécessaires pour paramétrer le jeu : les contrôles, la connexion, les graphismes et une chiée d’autres éléments y sont présents. On peut également configurer son jeu tout bêtement en passant par la console, accessible par la combinaison ctrl + alt + ² (ou ² si com_allowconsole est à 1).
Il faut savoir qu’il n’est pas possible d’enregistrer plusieurs configurations dans un seul fichier mais qu’il est tout à fait possible d’en créer un pour le solo et un autre pour le multi par exemple. Une fois configurés, on pourra les appeler dans l’autoexec.cfg ou la console à l’aide de la commande exec xxx.cfg. A noter que après avoir modifier certains paramètres graphique, il est théoriquement nécessaire de relancer le jeu. En pratique, un vid_restart dans la console suffit.
Les binds
Pour ceux n’ayant jamais touché à un Quake, expliquons rapidement comment préparer des binds d’actions. On utilise pour ça tout simplement la commande bind qui prend comme paramètres la touche concernée et les actions à attribuer, séparées par des points-virgule.
bind M say olol jtqi niaue
Il est aussi possible de se servir de la commande set pour enregistrer une macro qu’on pourra exécuter avec vstr :
set phrase « say zomfg ?!; say fucking rg whore§ »
bind M vstr phrase
A noter qu’il semble malheureusement impossible d’attribuer à une unique touche plusieurs commandes débutant par _, comme _moveUp (qui permet de sauter) ou _impulse x (qui accomplit une action prédéfinie, comme tirer ou changer d’arme)
La config du joueur occasionnel
L’objectif de cette configuration est d’apporter un bon équilibre entre qualité graphique et lisibilité de l’action. Tout d’abord, on peut commencer par supprimer le bump mapping : le gain en FPS est négligeable (entre 0 et 5%) mais certaines textures paraissent beaucoup plus épurées. Ensuite, on peut aussi virer les ombres. De toutes manières, on n’y fait pas vraiment attention dans le feu de l’action. On continue en supprimant d’autres effets inutiles : le muzzle flash et les particules, puis on augmente l’angle de vue à 110°.
seta com_allowconsole 1
seta r_skipbump 1
seta r_shadows 0
seta g_muzzleFlash 0
seta g_projectilelights 0
seta g_skipParticles 1
seta g_fov 110
Au final, on a un résultat pas trop dégueulasse graphiquement et qui offre un léger gain de FPS et de lisibilité par rapport à la configuration de base. Il n’y a malheureusement pas de formule magique pour vraiment booster son framerate : paramétrer la finesse des texture n’a strictement aucune influence et l’impact de la résolution d’écran est assez faible. En passant de 1280×960 à 1024×768 j’ai noté un gain de performances de l’ordre de 8%, gain qui n’augmentait pas en passant en 800×600 ou en 640×480.
Afin de tester l’influence de chaque paramètre séparément, une bonne technique consiste à enregistrer une démo puis à la visionner en tant que timedemo, c’est à dire en faire un benchmark.
recordDemo mademo
stopRecording
timedemo mademo.demo
Ce type de démo permet d’effectuer des benchmarks mais n’est pas vraiment pratique pour montrer vos meilleurs frags à tous vos copains dans la cour de récréation. Pour cela, les netdemos permettent d’enregistrer plusieurs minutes de jeu sur seulement quelques Ko de données. Les commandes pour les lancer et les lire sont recordNetDemo mademo et playNetDemo mademo.netdemo.
La config «regarde maman, je suis un tru3 r33t !!1!»
L’objectif dans cette configuration est d’obtenir la meilleure lisibilité, quitte à avoir un jeu graphiquement dépassé de 10 ans. Comme dans la configuration destinée au joueur occasionnel, on commence par dégager les éclairages dynamiques, le bump mapping, le muzzle flash et les particules :
seta com_allowconsole 1
seta r_shadows 0
seta r_skipbump 1
seta r_muzzleflash 0
seta g_projectilelights 0
seta g_skipParticles 1
seta g_fov 110
Ensuite, vient le problème des textures. Dans Quake 3, on pouvait facilement les étirer à l’aide de la commande r_picmip pour obtenir des graphismes bien plus lisibles que la normale. Etant donné que cette dernière a disparu dans le moteur de Doom 3, il faut utiliser une alternative. On pourrait tout d’abord être tenté d’utiliser le r_lodbias, qui donne un rendu quasiment similaire mais souffre d’un gros problème : il affecte également l’affichage du HUD.
Heureusement, une autre série de commandes permet d’améliorer la lisibilité des textures. Il s’agit des image_DownSize, divisées en deux principaux éléments. Tout d’abord, trois booléens déterminent si on doit tenir en compte ces paramètres. Ensuite, on règle la finesse des textures en définissant une limite. En pratique, cela donne un .cfg dans ce style :
seta r_lodbias 0
seta image_DownSize 1
seta image_DownSizeBump 1
seta image_DownSizeSpecular 1
seta image_DownSizeLimit 8
seta image_DownSizeBumpLimit 8
seta image_DownSizeSpecularLimit 8
La valeur 8 utilisée représente un bon compromis : elle permet d’avoir des icônes lisibles, de ne pas rencontrer les problèmes d’éclairage qu’on pourrait avoir avec des limites plus faible et offre une très bonne lisibilité. Par contre, ne vous attendez pas à économiser le moindre FPS : le gain est simplement nul. A noter que la variable r_skipbump étant à 1, le réglage de image_DownSizeBump et image_DownSizeBumpLimit est théoriquement inutile. Il n’est indiqué ici que pour illustrer le principe. Après avoir réglé ces paramètres, pensez à ajuster la luminosité et le gamma à l’aide des cvars r_brightness et r_gamma.
seta r_brightness 1.7
seta r_gamma 1
Pour finir, il ne reste qu’à libérer un peu de place à l’écran en dégageant l’arme.
seta ui_showgun 0
Vous aurez remarqué qu’on n’a pas parlé jusqu’ici des simple items, forceModel, enemyColors ou autres réglages de ce genre, et pour cause : ils ont purement et simplement disparu. C’est assez frustrant, d’autant plus que les modèles fournis ne ressemblent pas vraiment à des brightskins, et même en utilisant une bonne configuration on a parfois du mal à distinguer les armes et personnages dans le décor. On espère qu’un mod viendra régler ces problèmes, à la manière d’OSP ou CPM pour Quake 3 mais pour l’instant il faudra s’en passer.
En conclusion
Quake 4 ne semble malheureusement proposer que peu d’options de paramétrage en comparaison du troisième épisode. Il est cependant possible d’améliorer la lisibilité de l’action via certaines commandes, comme les deux configurations proposées le montrent. Il faut bien voir qu’elles ne sont ni parfaites ni exhaustives : il existe très certainement plusieurs dizaines de bidouilles permettant de gagner un FPS par-ci par-là ou de rendre les ennemis plus voyants, mais ça devrait déjà faire un bon début.
