Forum
Retour à la section mQ3
 Ecrit par Poil |
[DOC] - mQ3 |
 2010-06-14 21:36:06 |
|
|---|---|---|---|
|
intro : Le client affiche les informations recues par le serveur. Lorsque le client va plus vite que le serveur, il y a interpolation des infos entre 2 paquets. Quand le client va plus vite que le serveur mais qu'un paquet récent n'est pas encore arrivé pour le "temps" que le client veut afficher, il y a extrapolation des informations cvars : cl_maxpackets (entier) cl_packetdup (entier) snaps (entier) rate (entier) dev_nc_wrapnextpackettime (entier) dev_nc_wraptimedelta (entier) dev_nc_addtimedelta (entier) cl_timenudge (entier) description/configuration : cl_maxpackets : nombre maximal de paquets par seconde que le client va envoyer cl_maxpackets = cl_maxfps est une bonne valeur (typiquement 125) inutil d'envoyer trop de paquets, le serveur va devoir travailler plus et utiliser plus de bande passante descendante. cl_packetdup : duplication de chaque paquet emit 1 par défaut, mais 0 devrait bien fonctionner du moment qu'il n'y a pas de pertes de paquets, libère de la bande passante pour le client et le serveur snaps : nombre maximal de paquet que le serveur va envoyer au client snaps devrait être égal ou inférieur a sv_fps snaps = sv_fps semble assez sur d'utilisation rate : bande passante maximale des données que le serveur peut envoyer au client 25000 devrait être suffisant, autrement augmenter jusqu'a 50000 dev_nc_wrapnextpackettime : le client essaye d'être le plus proche possible du temps serveur (serverTime) mais il se peut qu'il s'en rapproche de trop, auquel cas le client extrapole un cycle client (client frame). permet de régler l'intervalle de temps avant d'extrapoler. par défaut le client extrapole lorsqu'il est à 5ms du serveur. dev_nc_wraptimedelta : lorsque le client extrapole, il ralenti l'execution du jeu (cgame) (afin d'éviter d'extrapoler trop souvent ?) par défaut ralenti de 2 msec dev_nc_addtimedelta : lors de chaque cycle client, le "sens" du jeu est accéléré un peu afin d'être le plus proche possible du temps serveur par défaut on rajoute 1 msec chaque cycle cl_timenudge : permet d'additionner une constante au temps serveur du client une bonne valeur positive permet de s'assurer de ne jamais extrapoler et donc avoir un jeu fluide quelque soit le framerate puisque les trames intermédiaires (entre 2 paquets server) du client sont interpolées. Une valeur négative permet d'avoir un serverTime client plus proche du temps serveur au moment de l'execution du paquet. Cela permet de compenser le temps de transports des informations et donc avoir une meilleure "réponse" Une trop grande valeur négative ? le jeu va afficher une trame avec un temps serveur plus grand que celui du dernier paquet recu. Les positions affichées seront peut être celle du prochain paquet ou pas. cl.serverTime = cls.realtime + cl.serverTimeDelta - timenudge; autres informations : Il y a des outils assez pratique pour jouer un peu avec les valeurs, qui sont 2 cvars : cl_showtimedelta et cg_lagometer bind x "toggle cl_showtimedelta" permet de ne pas saturer l'affichage plus facilement cl_showtimedelta montre la différence entre le dernier temps serveur recu et le temps client avec le facteur d'ajustement (timedelta) <FAST> est affiché lorsque le client est trop en retard sur le serveur avec en prime un saut dans l'affichage coté client <WRAP> est affiché lorsqu'une trame est extrapolée. Le but du jeu de la configuration est d'éviter a tout prix les "<FAST>", sans avoir trop de "<WRAP>" (addtimedelta et wraptimedelta pour régler ca) Pour le lagometre un rapide résumé de la page wikipedia : (autre source : http://earthli.com/quake/lagometer.php) Le lagometre est composé de 2 parties : haut et bas. Haut : 1 pixel par trame affichée (client) bleu = interpolation entre 2 "snapshots" valides jaune = extrapolation a partir du dernier paquet valide la hauteur est proportionnelle au temps le mieux est d'être toujours en bleu mais de faible hauteur Bas : 1 pixel par paquet recue du serveur (souvent plus lent que la barre du haut donc) rouge = paquet perdu (packet loss) vert = paquet bien recu jaune = paquet bien recu, aucune information perdue mais le serveur a sauté l'envoie d'un paquet pour rester sous le "rate" (et refait un nouveau paquet avec les anciennes + nouvelles infos) la hauteur est proporionnelle au temps de transport du paquet (ping) |
||
| Is it a Bird? Is it a Plane? No, it's Super Poil !!! |
|||