Optimisation

- En fonction de votre quantité de ram, vous pouvez autoriser le jeu à utiliser plus de mémoire vive que celle allouée par défaut (voir comment faire ci dessous). Il est en général recommandé d'allouer la moitié de votre ram au jeu. Mais ceci depend encore de la quantité que vous avez.

-Pour les ordinateurs possédant 512 Mo de ram, la quantité par defaut utilisée etant déjà de 256 Mo, il est théoriquement inutile d'y toucher, mais parfois, on peut constater de meilleures performances lorsque celui ci est réglé sur 512 Mo ( à ce moment la, c'est windows qui gère seul ce qu'il doit prendre pour tourner correctement avec le jeu de lancé).
Pour les ordinateurs possédant 1024 Mo de ram, il est donc conseillé de mettre 512 Mo pour HL2.exe
Le processus ne dépasse que très rarement ce seuil, voir jamais, vous pouvez tout de meme allouer 1024 Mo pour le processus, mais les différences ne se feront théoriquement pas ressentir. Au dessus de 1024 Mo de ram, vous pouvez laisser sur 512 ou 1024, au choix.
Pour paramétrer la quantité de ram à utiliser, vous devez entrer dans les propriétés de lancement du jeu (clic droit sur le jeu, puis propriété). Dans l'onglet "Général", cliquer sur "définir les options de lancement". Une ligne apparaît alors pour entrer les commandes. Celle du screenshot permet de lancer la console au lancement, et de régler le heapsize sur 1024 Mo.


La commande -heapsize permet donc de définir cette quantité de ram. -heapsize 1048576 permet d'allouer 1048576 octets, ce qui correspond à 1024 Mo. Pour trouver la valeur, il suffit simplement de multiplier la quantité souhaitée par 1024 (1024*1024 => 1048576). Pour allour 512 Mo, 512*1024 = 524288. La commande pour allouer 512 Mo sera donc -heapsize 524288.


- Les options graphiques vous permettent d'augmenter vos FPS pour jouer avec une meilleur fluidité. Si votre machine ne suit pas, il est recommandé de baisser la qualité graphique pour augmenter votre fluidité. /!\ Il ne faut pas se limiter à 24 FPS comme une TV pour avoir une sensation de fluidité. De plus vous devez tenir compte des baisses de FPS lors de multiples combats. Par exemple, si vous avez 24 fps en vous baladant dans la map, il est sur et certain que vous tomberez bien bas lorsque vous verrez à l'écran 2-3 joueurs en train de se tirer dessus, le tout mélangé avec quelques explosions de grenades, que vous tomberez sous la barre des 10 FPS, et la, c'est quasiment injouable. Pour ne pas ressentir de baisse de FPS et avoir une bonne impression de fluidité, il est conseillé d'en avoir environ 60 minimum en temps normal (c'est à dire en se baladant sur la map).
/!\ Pour des conditions optimales, le 100 FPS est recommandé. Il n'est pas question ici de savoir si l'oeuil distinguera la différence entre 100 FPS ou 60 FPS, mais il est question de netcode (décrit plus bas dans les configurations internet). En effet, il faut savoir qu'un des défaut majeur du moteur est d'être limité en cmdrate par les FPS. On verra plus loin l'utilité du cmdrate, et pourquoi il est préférable de l'avoir a 100. Ce qui implique de pouvoir se rapprocher le plus possible des 100 FPS pour des condition OPTIMALES de jeux. Bien évidemment, un FPS a 66 avec un cmdrate de 66 n'est pas énormément pénalisant.

- Plusieurs commandes sont disponibles en plus des options graphiques. Vous pouvez les écrire dans un fichier nommé autoexec.cfg (pour le créer, voir la partie "configuration / commandes" ) Voici une listedes principales mais il en existe beaucoup d'autres influant plus ou moins sur la qualité / les fps. (a updater)
Les commandes principales influant sur la qualité graphique sont:

cl_phys_props_enable 0 // Désactive les petit objets qui ne dérangent pas les déplacement. (petite boites, briques ...)
cl_ragdoll_physics_enable 0 // (Efface les corp des perso mort. Pas de corp par terre)
cl_ragdoll_collide 0 // (Pas de gestion de collision entre les corps)
cl_show_splashes 0 //(pas d'effet d'éclabousures quand on tire dans l'eau)
fog_enable 0 //(désactive le brouillard)
fog_enable_water_fog 0 //(désactive le brouillard au dessus de l'eau)
mat_antialias 0 //(désactive l'anti aliasing)
mat_bumpmap 0 //(désactive le bumpmapping)
mp_decals 8 //(n'affiche que 8 tag perso des joueurs)
r_decals 10 //(affiche que 10 decals du jeu en même temps. 1 decal = 1 impact de balle, une tache de sang ...)
mat_fastspecular 0 //(désactive le fast spécular lighting. La plupart des reflet devienne inactifs. Ex: sniper scope)
mat_specular 0 //désactive le specular lighting
r_dynamic 0 // désactive les lumière dynamique
mat_forceaniso 0 //(désactive le filtrage aniso)
mat_forcemanagedtextureintohardware 1 //(je sais pas trop, mais il parait que ca aide un peu les vielles config biggerGrin.gif )
mat_hdr_enabled 0 //(Désative la gestion du HDR)
mat_picmip 2 //(Texture peu détaillées)
mat_trilinear 0 //(désactive le filtrage trilinéaire)
r_rootlod 2 //(Qualité des models généraux pas très élevés)
r_rainradius 0 //(désactive la pluie)
r_shadows 0 //(désactive les ombres. Peu reommandé car elles sont utiles sur source)
r_waterforceexpensive 0 //(Une Optimisation de l'affichage de l'eau, mais je sais pas trop quoi)
r_3dsky 0 //(Désactive les texture 2D autour de la map. Ex les buildings qui font croire a un centre-ville)
rope_smooth 0 //(désactive l'anti aliasing des cables)
rope_wind_dist 0 //(désactive l'effet de vent qui fait bouger les cables)
r_worldlights 1 //(Une seule source de lumière)
r_modellodscale 0.6 //(abaisse la qualité des personnages avec la distance plus vous êtes loins, plus la qualité du perso baisse).

- Vous pouvez aussi forcer votre carte graphique à utiliser un DirectX inférieur à celui qu'elle peut gérer. Par exemple, si votre carte a du mal a gérer le directX 9, telle une 9600 par exemple. Vous pouvez la forcer à utiliser un directX 8.1 ou 8.0, voir même un directX 7 au détriment de la qualité graphique biensur. Pour cela, il suffit d'ajouter un ligne dans l'autoexec, comme les commandes si dessus.

Pour forcer en directX 9 => mat_dxlevel 90 (95 pour les dernières nvidia en directX 9.0c)
Pour forcer en directX 8.1 => mat_dxlevel 81
Pour forcer en directX 8.0 => mat_dxlevel 80
Pour forcer en directX 7 => mat_dxlevel 70
Pensez aussi à réduire la résolution de jeu si votre machine est difficulté.

- La commande fps_max 101 permet d'avoir une bonne fluidité sans ressentir de ralentissements. En passant d'une scène peu chargée a une scène très chargées, vous sentez une légère baisse de FPS en passant de 250 a 90 par exemple. Ce qui peut être genant. Par contre si vous passez de 100 a 90, le ralentissement est beaucoup moins perceptible.
De plus, si l'on ne tien pas comptes des variations de FPS, Il est inutile de monter plus haut que la fréquence de rafraîchissement de votre écran, vous ne verrez pas plus d'images par seconde que ce que peux vous afficher votre ecran, par contre, si la fréquence de rafraîchissement de votre écran est inférieure à 100 Htz, vous devez tout de même laisser une valeur minimum de 100 pour ne pas que vos FPS brident votre cmdrate comme il est précisé plus haut. Par exemple si vous avez un ecran lcd a 60 Htz. Il faut désactiver la synchro verticale et avoir un fps_max > 100 pour ne pas limiter le cl_cmdrate a 60.


- La console permet d'effectuer plusieurs réglages sur le jeu qui ne sont pas accessibles par les options. Vous pouvez l'obtenir au lancement du jeu en ajoutant -console dans les options de lancement, comme sur le screen de la partie décrivant le heapsize. Par contre vous risquez de la perdre en pleine partie si vous la fermez, et ce, sans pouvoir la récupérer. Pour ca, on va pouvoir rentrer ces lignes dans l'autoexec.cfg

con_enable 1
bind "'" "toggleconsole"

Ca va vous permettre d'avoir la console en plein jeu en appuyant sur la touche ² et de pouvoir la réouvrir même après l'avoir fermée.

- Coté client

- Ce qui nous intéresse ici, c'est d'être synchro avec le serveur pour avoir un maximum de tick (shéma du jeu) par secondes, et donc une meilleur qualité de jeu. La majeur partie des serveurs étant en tickrate 100, et la majorité des joueurs possédant une connection haut débit, on peut partir des meilleurs valeurs. Ces valeurs peuvent être entrée dans l'autoexec.cfg (voir la partie configuration pour créer le fichier).

On va donc simplement entrer ces valeurs.

cl_cmdrate 100 (on envoie vos actions, ou tick [déplacement, tirs...]) 100 fois par secondes, au serveur)

cl_updaterate 100 (on reçoit les actions du jeu, ou tick, 100 fois par seconde, par le serveur, si ce dernier est en tickrate 100)

cl_interpolate 1 Permet d'avoir une image fluide des joueurs. Avec l'interpolate a 0, si un joueur envoie 20 paquets par seconde au serveur (cause: fps faibles, ou cmdrate mal réglé) alors vous verrez ce joueur saccader (on dit aussi se téléporter) car vous n'aurez que 20 images par secondes de ce joueur.
Avec l'interpolate à 1, le client va combler le manque de position du joueur par des images (tick) insérée entre chaque déplacement du joueur avec une trajectoire calculée en fonction des 2 dernière positions reçue, pour ainsi le rendre plus fluide. Inconvénient: les images générée par l'interpolation ne sont pas touchable. Comme si c'etait un model virtuel etant donné que c'est géré uniquement chez le client.

cl_interp_ratio 1 Temps / cl_updaterate sur lequel est généré l'interpolation. C'est aussi le temps de retard qu'aura l'affichage par rapport au jeu. Voir description plus bas. (Lag Compensation)
si votre cl_updaterate est a 100 et que votre ratio est a 1 vous aurez un temps d'interpolation de 0.01, ce qui correspond a l'ancienne variable cl_interp 0.01.


rate 1048576 ou moins. C'est le taux de transfert maximum (serveur => client uniquement). Il s'agit en fait de la limite fixée par le source Engine. Si votre connection n'accepte pas ce débit, il est préférable d'en informer le serveur et de baisser votre rate. Un rate 1048576 correspond donc a une connection de 1 Mo/sec plus couremment exprimée par 8 Mbits/sec. Si vous avez une connection 512 K de bonne qualité (soit environ 64 Ko/sec de récéption max, vous pouvez baisser votre rate a 65536.
Pour une classique connection 1 MBits (128 Ko/sec) vous pouvez le mettre a 131072. Pour les détenteur de très mauvaises connexions ADSL, (ligne 512 très longues et de très faible qualité, ligne 256K etc...) Vous pouvez vérifier l'etat de vote downlad maximum et régler le rate en conséquence.
Il faut savoir que le serveurs possèdent leur propres restrictions sv_maxrate et sv_minrate qui définissent les maximum et minimum qui peuvent être appliquée par le clients. Beaucoup de serveur sont encore en sv_maxrate 30000 ou sv_maxrate 25000. Il est clair que dans ce cas, avoir un rate a 1048576 ne servira a rien puisque le serveurne vous everra pas plus de 30 ou 25 Ko/sec. C'est un débit qui suffit dans la plupart des cas, mais en phase intense, ce débit peut instantanément être largement dépassé. C'est pourquoi il est préférable de débrider totalement cette limite haute via la commande sv_maxrate 0. De cette manière, le débit maximim entre serveur et client sera d' 1 Mo/sec. Le serveur possède aussi une restriction minimum du rate. Si le serveur est par exemple réglé sur sv_minrate 5000 (proche du défaut mais plutot mauvais), cela veux dire qu'un client pourra régler son rate sur 5000, ce qui revient a lui envoyer pas plus de 5 Ko/sec. Ca revient a jouer en 56K et ca devient vite pénible. Pour cela, vous pouvez augmenter la valeur sv_minrate de votre serveur a environ 20000 ou 30000 ce qui evitera au client de simuler une connexion trop lente (pas en dessous de 20 Ko/sec).
Ca peux paraitre faible face aux connexions actuelles, mais beaucoup de personnes sont encore loins des dslams avec des lignes de très basse qualité, et leur débit en est souvent amoindri. De plus, 20 Ko/sec c'est largement suffisant en situation de jeu "normale".

cl_predict 1. Permet d'avoir un jeu plus réactif chez le client. En fait, le jeu n'a pas besoins d'attendre une confirmation du serveur pour effectuer certaines action comme les animation de tir ou les déplacement.
Sans prédiction coté client, il faut que le client envoie l'info de son action au serveur, ensuite le serveur confirme l'action au client, et la, le client effectue son action. Avec la prédiction, le client envoie ses actions au serveur et c'est tout. Il arrive (rarement) que le client fasse quelques erreur de prédicion, notemment en ce qui concerne les déplacement. Si le client s'est trop déplacé par rapport au jeu réel (controlé par le serveur), le serveur va corriger la trajectoire chez le client. C'est en général tellement léger et peu fréquent qu'on ne s'en apercoit pas. (voir le cl_smooth)

cl_smooth 1 Cette valeur autorise le serveur à adoucir la correction de vos erreurs de predictions. Par exemple lorsque vos déplacement ont été trop important (tout est relatif encore, ca reste très faible en général) du coté client, le serveur va vous replacer très doucement à votre bonne position.

Si cette valeur est a 0, le client vous replacera brutalement et la vous vous apercevrez du changement. La prédiction n'est valable que pour vos déplacement et vos tirs.

cl_smoothtime 0.01/ 0.02. C'est le temps maximum autorisé pour"smoother". C'est a dire pour vous replacer en douceur par rapport au serveur. Si l'erreur de prédiction est trop importante pour être corrigée en douceur dans le temps imparti, alors vous êtes replacé brutalement a votre position.
Cet variable doit être assez faible car si votre PC vous replace a votre position en 0.1 sec, vous aurez un décalage entre l'endroit d'ou vous voyez le joueur et l'endroit ou vous êtes réellement pour le serveur. Et les 2 différentes trajectoires de balles etant colinéaire avec un point de départ différent, n'auront pas le même point d'arrivée (impact). Mais cette valeur ne doit pas être trop faible car dans ce cas, le moteur n'a pas le temps de vous smoother et vous êtes brutalement replacé.

cl_lagcomp_errorcheck 0. Passez le a 1 si vous avez des problème de touchabilité dû a un choke ou loss que vous ne pouvez pas corriger. (saturation de votre BP par rapport a ce que vous envoie le serveur)

- Coté serveur

On vas déjà voir comment se débrouille le serveur pour gérer les latence générée par les différentes connexions. Ca s'appelle la compensation de Lag.


[left]Voila une petite explication du fonctionnement du mécanisme de compensation de lags. Dans l'exemple, Nous somme sur un serveur tickrate 100, avec un ping de 50 ms et des valeur network correctes (cmdrate 100, updaterate 100, et rate 25000, donné le plus souvent sous la forme 100/100/25000).
Pour comprendre le fonctionnement on va suivre le trajet d'une information reçue, ainsi que celui d'une information envoyée suite a une réaction du joueur, et voir comment le serveur analyse le tout (en simplifiant au maximum).
Ceci et théorique. Le lag compensation comporte de petit bug, il suffit de se rendre sur le forum steam pour le constater



Dans cet exemple, le serveur envoie la position d'un joueur à 15,03 sec. Le ping étant (temps mis pour faire aller retour) de 50 ms, le trajet d'un aller simple durera 25 ms. L'information arrive donc 25 ms plus tard chez le client, soit a 15,055 sec.

C'est la qu'entre aussi en jeu le cl_interp. Pour pouvoir créer des positions supplémentaires sur la position des joueurs dont vous ne recevez que peu d'informations, votre pc vous fait joueur dans le "passé". Pas 15 ans en arrière non plus, juste la valeur cl_interp de retard. Ca permet de laisser 0.01 ou 0.02 secondes d'avances au pc, soit 1 ou 2 tick, pour pouvoir calculer les points de trajectoire intermédiaires et ainsi inventer des positions pour rendre les joueurs plus fluides.

Donc entre le temps ou le serveur vous envoie une info et le temps ou vous la voyez à votre écran, il s'est ecoulé 0,045 sec. (rien de grave théoriquement puisque le serveur va compenser tout ca).
Suite a ses 0.045 sec, il faut ajouter le temps de réaction du joueur (client) avant qu'il tire. On va dire qu'il met 0.05 sec pour l'exemple ce qui nous amène a 15,125 sec. La, pas de décalage entre le pc et l'affichage, l'information est directement envoyée a 15,125 sec.
Par contre, on retrouve un nouveau décalage de 25 ms dû au ping (50 ms) entre le moment ou le client recoit l'information et le moment ou le serveur la reçoit.

Au final, le temps qu'il s'écoule entre le moment ou le serveur envoie la position d'un joueur et le moment ou il reçoit l'information de tire du joueur et assez conséquent, même si l'on enlève le temps de réaction du joueur. Et ca parait énorme avec un ping de 80 ms et un cl_interp par défaut (0.1). Ca nous donnerais un décalage de 180 ms sans le temps de réaction.

C'est pour ca que le serveur va compenser tout ce lag (sv_unlag 1). Le serveur connait vos paramètres (ping + cl_interp) Il va donc facilement pouvoir calculer le temps qu'il a fallu au informations pour circuler à travers le réseau. Ainsi, a la réception de l'info de votre tir, le serveur va retourner voir ses "archives".
A 15,15 sec (réception de votre commande tir), il va retourner voir comment était le jeu au moment ou il vous a envoyé les info de positions. (temps réel - temps de latence - temps d'interpolation)
Ainsi, rien est décalé. Mais ca c'est théorique car l'interpolation introduit un retard d'affichage de 100 ms apparemment et ceci quel que soit le cl_interp chez le client. Ce qui a amené un lourd débat sur la valeur cl_interpolate a adopter.

Note: La valeur cl_interp est maintenant remplacé par cl_interp_ratio / cl_updaterate, mais ca ne change rien. Ca reste un temps d'interpolation

Pas mal expliqué mais c'est vrai qu'on s'y perd un peu ^^'

Merci pour les optimisations aussi

j'ai compris pourquoi j'avais des fps de ......,j'ai une cg grillée

Sympa, t'en est rendu compte comment ?

sur les autres jeux.

Est ce qu'une bonne ame aurait un autoexec.cfg tout frais deja tapé, apparement je ne tourne pas au delà de 30 fps !!!! pas cool

alors pour l'autoexec je croi qu'avec la nouvelle beta sa marche pas(en tout cas pas pour moi et gaby lol) mais je pourrai te filer celle que j'utilisai,sinon en attendant rentre dans ta console les ligne qui font le plus de gain de fps

ok mais bon tu dois les retaper a chaque fois ?????

sa depend sur certain pc cela ce sauvegarde directement

Quand je pense que j'ai jamais verifier mes Fps jusqu'a aujourdhui et que je trouvai que c'était plutot fluide avec en action une moyenne de 15 fps j'm'en remet pas, après moulte trifouillerie il semble que j'oscille en pleine action de 30 à 45 fps avec un choke de 50 bref je crois que je vais laisser tout ça de cote

Mais me parler plus de fps avant au moins 5 min que je me détende