Astuce pour diminuer les coups de lag

[ChandlerBing82]

oui et la logique vu qu'on est quand meme dans un jeu vidéo ou le réglage du réseau prend une part énorme, aurait voulu que la priorité soit donné au calcul suivant les rates.

Malheureusement, quand je lis que le fps_max bride le cmdrate, ca me fait bondir mais je ne suis pas développeur chez valve :/

[karli]

complètement d'accord, ils mêlent tout et c'est bidon. Je suis encore libre de pouvoir déterminer les frames que je veux afficher sur MON pc sans que cela me nuise sur un serveur, non mais !

[karli]

En gros pour résumer l'idéologie de css : claquez du pognon en grosses grosses configs ou soyez handicapés au niveau performance.

[SekYo]

Non Balder c'est faux justement. Ton cmdrate de 100 ne tiendra pas, tu vas voir ton "Out" descendre au niveau de tes FPS.

Si de manière générale il est plus agréable/facile de jouer avec une bonne config c'est du fait de la fluidité graphique, stout. La limite des 24 imgs/sec ne s'applique pas ici et avec un nombre faible de fps, ton affichage sera plus saccadé ( donc pour viser, c'est plus dur ), tes actions seront prises en comptes plus tardivement ( à 20 fps tes actions sont checkées 20 fois toutes les secondes soit toutes les 50 ms ( oui plus que le ping moyen ^^ ), à 100 fps elles le sont toutes les 10 ms ).

Etc...

Et sauf à avoir 10 fps constant ( et donc 10 de cmd ) les petites baisses de FPS ne genent que le joueur concerné, pas le serveur. Le mécanisme d'interpolation compense assez efficacement ces petites baisses ( quand une HE explose dans une salle remplie d'objets par exemple ).

@Chander : Certes, mais c'est beaucoup, beaucoup, beaucoup plus complexe de donner la priorité aux rates ( car ca implique de dissocier les 2, j'vais pas revenir dessus ).

[ChandlerBing82]

c'est a la conception qu'il faut le définir, c'est pas plus complexe ca n'a pas été fait comme ca c'est tout [:spamafote]

De plus sauf erreur de ma part, les dégats provoqués par les HE sont gérés par le serveur, de meme que le résultat de l'explosion (les corps qui font des vols planés, les caisses qui s'envolent, etc..) sont aussi gérés par le serveur

[SekYo]

Pour les HE je le pensais aussi... Mais avec mon ancien PC à chaque explosion de HE, sur office notamment, j'avais une grosse, grosse chute de FPS. M'est avis que le serveur ne calcule pas tout dans l'histoire, m'enfin là faudrait demander à Valve.

Sinon si si c'est plus complexe, parce que faut du multithreading, jvé pas y revenir ( mais je suis d'accord, il faut que cette optique multi thread soit pensées dès le début de la conception )

[OraSmok8]

nan mais les trames réseaux ne sont pas dépendantes de l'affichage.

Simplement l'affichage ET les trames réseaux sont toutes 2 dépendantes de la même chose : le moteur physique.

Si le moteur physique ne calcule que 30 frames par seconde, l'affichage restera limité à 30 et les données envoyées au serveur aussi

Meme si de nombreux éléments physiques sont calculés au niveau serveur, ceci est AUSSI calculé en local, et ceci afin de compenser le ping.

Imaginons que vous êtes connecté sur un serveur avec 500ms de ping : vous déplacez vers 1 mur à fond les bananes : est ce que vous allez traverser le mur pendant 1demi seconde avant de vous arrêter? Non, car votre jeu en local calcule déjà qu'il va y avoir collision et vous en empeche.

Idem pour les grenades etc : ceci est déjà calculé en local pour des besoins de fluidité : et oui la grenade part de suite et son jeté est fluide même si la connexion ne suit pas.

Ce sont ces calculs qui sont gourmants avec Source et qui limitent à la fois l'affichage et les trames réseau

Les calculs au niveau serveur sont plutôt là pour synchroniser le tout (collisions entre joueurs, tirs et dégats), et éviter certaines formes de triche (noclip etc)

[inconnu49]

c'est a la conception qu'il faut le définir, c'est pas plus complexe ca n'a pas été fait comme ca c'est tout [:spamafote]

De plus sauf erreur de ma part, les dégats provoqués par les HE sont gérés par le serveur, de meme que le résultat de l'explosion (les corps qui font des vols planés, les caisses qui s'envolent, etc..) sont aussi gérés par le serveur[/quotemsg]En fait cela dépend de la map, certaines entités qui ont des contraintes physiques peuvent être géré par le client comme les débris...

Les cadavres sont, je crois, aussi géré par le client car le résultat n'est pas forcement le même entre deux clients différents (J'ai déjà vu cette différence en Lan), ce qui ne serait pas le cas si c'était le serveur qui donnait le résultat.

[Arcanos]

J'ai quand même l'impression que c'était séparé sur 1.6 pour ce qui est rates et affichage...

Un pc peut calculer 100 actions tout en n'affichant qu'une partie de celles-ci, surtout si le client ne doit envoyer que ses propres position/actions (ce qui est nettement moins gourmand que de faire un affichage), c'est une dissociation qui aurait été très bénéfique au jeu.

Maintenant, faudrait que quelqu'un avec 100fps constants face l'essai de jouer en fps_max 100 et 50 pour voir si les données en up sont modifiées ou non, ça trancherait le débat.

Et si il y a bien baisse alors ça tuera le mythe du "tickrate 100 ça touche" car ça touche pas pour tout le monde

[yakrn]

j'ai un écran plat et on dit qu'avec les écrans plat on peut pas avoir plus de 60 fps ?

[LeSage]

les fps limitent les informations que tu envois mais pas cellle que tu reçois

le tick 66 c'est très correcte, il n'en faut pas plus pour avoir un jeu fluide et au moins on entendrai moins :

les serveurs coûtent chers

pour jouer à css il faut une bonne config

et en plus ça équilibrerai les joueurs au niveau rate

bref le tickrate 100 c'est un peu inutile, surtout sur internet

mais comme on est tous parano, égoïste et que le tickrate 100 à des avantages on préfère avoir du tick 100

[Arcanos]

YakrN, ce qu'il se passe avec les tft c'est qu'ils ont généralement une fréquence de rafraîchissement faible (60 ou 75Hz).

En 60Hz, il se rafraîchit 60fois par secondes => il ne peut afficher que 60images différentes à chaque secondes, les autres sont perdues. Donc à l'affichage tu es bel et bien limité à 60fps.

Ca reste le dernier avantage des CRT qui arrivent à des taux de rafraîchissement de 100Hz dans d'assez hautes résolutions si on y met le prix...

[LeSage]

ça me parrai bizar ton expliquation, nos crt si il sont en 60hz n'empchent pas d'avoir plus de 60fps si la syncronisation verticale est désactivé

[Psylohk]

Oui, un tft n'empeche pas du tout le jeux d'avoir plus de 60 ou 75 fps si la synchro vertivcale est désactivée.

YakrN, ton ecran plat te limitera a 60 images par secondes, mais c'est c'est propre a l'ecran, ca n'empeche pas le jeux de tourner en 100 fps ou plus. D'ailleur c'est pareil pour une bonne partie des joueurs en CRT, je pense qu'il y en a une bonne partie qui jouent avec 85 HTz ou moins et qui ont bien plus de fps que ca

[Arcanos]

Bah LeSage, c'est pourtant la vérité. Si ton écran est en 60Hz, tu n'auras pas plus de 60images par seconde à l'écran. Maintenant évidemment tu peux laisser le jeu en calculer plus mais ça ne servira à rien pour toi (par contre, sur le net tu permettras de respecter un tickrate plus haut vu que les positions auront été calculées).

Pour les crt, on trouve quand même nettement plus d'écran supportant le 80Hz (voir +) en 1280x1024...

[Jobran]

Bonjour à tous,

ce topic est plutot enrichissant, notamment le fait que le taux de rafraichissement de mon écran soit de 85hz en 1024 et que "techiquement" je ne puisse pas dépasser le tick 85 me fait réfléchir, je vais peut etre passer en 800 pour avoir 100hz.

Bref, ce qui m'ennuie c'est que personne n'a répondu au titre du topic.

Alors fesons d'abord quelques hypothèses:

- on est sur un "bon" serveur, c'est à dire avec un tick stable (prenons 100 par exemple)

- on a une "bonne" connexion, type ADSL 2+ de plus de 20 méga, avec surtout un temps de latence inférieur à 30 (avec les réglages rate 30000 ; cmdrate 100 ; updaterate 100)

Donc d'après ce que j'ai pu lire, s'il y a des coups de lag, ça viendrait donc du client. On peut en (très) gros diviser le travail du client par 2:

- calcul

- rendu

qu'on peut assimiler à:

- cpu

- gpu.

C'est un peu cartésien, mais je crois que l'essentiel est là. Dans de bonnes conditions (citées en hypothèses), soit les coups de lag sont dû au CPU limited, soit au GPU limited, ou... au pire des cas, les 2 limitent les fps.

Alors maintenant comment fait-on pour savoir quand le GPU atend le CPU (cpu limited) ou inversement? Y'en a-t-il un qui est plus important que l'autre?

[SekYo]

Le plus facile pour le savoir ? Overclocker et/ou downclocker ton CPU ou ton GPU. Prenons le cas du CPU.

Réglages initiaux, tu lances une session de test, tu regardes tes FPS moyens.

Tu Overclock ton CPU, tu relances une session de test, partant de là deux options :

1) Y a pas de changement

2) T'as plus de FPS.

Si y a pas de changement, il faut peut être réessayer d'OC un peu plus... Maintenant j'avais un P4C 2.8GHz et sous Source j'étais CPU limited, j'ai senti des gains de FPS dès l'OC à 2.9-3.0 GHz, donc en général ca va assez vite. Donc si après un OC conséquent y a toujours pas plus de FPS, on peut supposer que c'est ton GPU, ta Carte Graphique qui limite.

Si t'as plus de FPS, on peut supposer que tu es CPU limited.

Disons que c'est comme ça que j'en ai déduit chez moi que j'étais CPU limited.

Maintenant évidemment tu peux laisser le jeu en calculer plus mais ça ne servira à rien pour toi (par contre, sur le net tu permettras de respecter un tickrate plus haut vu que les positions auront été calculées).

J'ai toujours eu un doute là dessus... Sinon quel intérêt même pour les pgm de jouer à Q3 ou 1.6 avec 200+ fps ? Y a pas d'écran même CRT qui sont à 200 Hz

[Jobran]

J'avais essayé en changeant la résolution et en gardant un oeil sur le fps du net_graph, mais c assez difficile à faire... je vais essayer ta méthode dans la journée.

Sinon à qui s'adresse ta dernière question?

[Jobran]

Bon, au départ je dois dire que j'étais réticent à utiliser le "VIDEO STRESS TEST" pour savoir ce qui limitait mes fps. En effet, ce test est plutot linéaire, et ne simulait pas vraiment les montées soudaines d'informations (ça c'est mon sentiment).

En tout cas, selon les tests que j'ai réalisé avec, mes fps sont uniquement dépendantes de mon AMD Athlon 64 3500+ :

3500+ @ 2.2 Ghz (d'origine) + X800 XT PE @ 520/560 (d'origine) = 148 FPS

3500+ @ 2.2 Ghz (d'origine) + X800 XT PE @ 567/594 (O/C) = 148 FPS

3500+ @ 2.667 Ghz (O/C) + X800 XT PE @ 520/560 (d'origine) = 167 FPS

3500+ @ 2.667 Ghz (O/C) + X800 XT PE @ 567/594 (O/C) = 167 FPS

(pour chaque ligne, j'ai refait le video stress test 6 fois, le résultat affiché est la valeur moyenne.)

Donc apparement je serais également CPU limited.

J'aimerais avoir vos avis sur ce protocole de test. Le trouvez-vous valable? Ce test simule-t-il bien les fps in game?

[snk14]

bonjour a tous, moi je constate le m^me problème pourtant j'ai un 4000+ et une 7800 gtx avant tout tourner bien depuis que je me susi remis a css c'est l'horreur je passe de 120 140 fps a 65 70 lors de gun fights c'est incompréhensible. Le truc c'est que je tape 8384 point a 3d mark 05 en 1024 donc où est le cpu limited la dedan ? après ma cg est o/c plus de point a 3d mark dans css change rien dans les autres plus fluides hmm un 4000+ c'est pas assez bien pour css ? MDR !!!!! help please

[Pinkes]

bonjour a tous, moi je constate le m^me problème pourtant j'ai un 4000+ et une 7800 gtx avant tout tourner bien depuis que je me susi remis a css c'est l'horreur je passe de 120 140 fps a 65 70 lors de gun fights c'est incompréhensible. Le truc c'est que je tape 8384 point a 3d mark 05 en 1024 donc où est le cpu limited la dedan ? après ma cg est o/c plus de point a 3d mark dans css change rien dans les autres plus fluides hmm un 4000+ c'est pas assez bien pour css ? MDR !!!!! help please[/quotemsg]

Je confirme que tu es "Cpu limited".

Maintenant, ne pas confondre "cpu limited" et perf pourries. Un 4000+ devrait déja te donner des résultats plus que corrects, même s'il restera l'élément qui limitera tes fps.(ce qui explique l'oc de la CG qui n'apporte rien dans le cas de Css)

[SekYo]

Le moteur Source fait beaucoup plus appel au CPU que certains autres moteurs, c'est pour celà par exemple qu'on peut avoir de très bons FPS sous Doom 3 et des fps pourries sous Source.

@snk : +1 Pinkes, ton 4000+ ne peut pas exploiter toute ta 7800GTX

[icemike68]

Le moteur Source fait beaucoup plus appel au CPU que certains autres moteurs, c'est pour celà par exemple qu'on peut avoir de très bons FPS sous Doom 3 et des fps pourries sous Source.

snk : +1 Pinkes, ton 4000+ ne peut pas exploiter toute ta 7800GTX[/quotemsg]

Tout ça c'est bien beau, mais c'est quoi les bonnes valeurs qu'il faut mettre aux différents paramètres avec un 3700 et une 7900GTO et une connexion ADSL à 2000?

- updaterate : 100

- cmdrate : 100

cl_updaterate : ?

cl_cmdrate :?

C'est ça qui nous intérresse et pas vos téhories!!!

:sol:

[Pinkes]

Tout ça c'est bien beau, mais c'est quoi les bonnes valeurs qu'il faut mettre aux différents paramètres avec un 3700 et une 7900GTO et une connexion ADSL à 2000?

- updaterate : 100

- cmdrate : 100

cl_updaterate : ?

cl_cmdrate :?

C'est ça qui nous intérresse et pas vos téhories!!!

:sol:[/quotemsg]

Tu remarques pas une ressemblance entre tes 4 variables ? :whistle:

cl_updaterate : 101

cl_cmdrate : 101

rate 25000

cl_interp 0.01

Joue de préférence sur des tickrates 100. Ça c'est ma "pratique" à moi, je sais pas si elle te conviendra.

[rFlex]

J'ai quand même l'impression que c'était séparé sur 1.6 pour ce qui est rates et affichage...

Un pc peut calculer 100 actions tout en n'affichant qu'une partie de celles-ci, surtout si le client ne doit envoyer que ses propres position/actions (ce qui est nettement moins gourmand que de faire un affichage), c'est une dissociation qui aurait été très bénéfique au jeu.

Maintenant, faudrait que quelqu'un avec 100fps constants face l'essai de jouer en fps_max 100 et 50 pour voir si les données en up sont modifiées ou non, ça trancherait le débat.

Et si il y a bien baisse alors ça tuera le mythe du "tickrate 100 ça touche" car ça touche pas pour tout le monde [/quotemsg]

Absolument pas, sous HL1 le système est le même.