Forum

Retour à la section mQ3


Strict Standards: Only variables should be passed by reference in /home/www/88cb96f23cd3f1f84e23bb6375feec0c/web/module/commun/bbcode.php on line 427
clockEcrit par poil [DOC] - mQ3 clock2010-06-14 21:36:06
superpoil.jpg 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 !!!
CONRAD
Développé par Poil - Graphismes de DarkDaV - Icônes sous licence Creative Commons (famfam, nuovo ...)
Durée de génération : 0.070044040679932 secondes