Scoreboard |
ITB
02:00
DASH
0
ITB
00:02
TSM
0
MOUZ NXT
02:01
TSM
0
ITB
02:00
ALTERNATE
0
Falcons
02:00
Virtus.pro
1
FaZe
02:00
OG
0
Verdant
00:02
Anonymo
0
BIG
01:02
Virtus.pro
0
Falcons
02:01
Complexity
0
Revenant
00:02
ECSTATIC
0
OG
02:01
AMKAL
0
BIG
02:01
GamerLegion
0
Cloud9
00:02
paiN
1
Verdant
01:02
Revenant
0
Verdant
01:02
Sampi
0
Falcons
02:00
M80
0
Complexity
02:00
Metizport
0
Revenant
01:02
Alliance
0
Thayu 
| Forum |
Et nos 3DMAX en 3-0 au... 
Comment créer ses... 
Recherche AK-47 hardened... Actualité de la scène |
Compétitions |
| Forum |
Argument tickrate bidon - 77 messages, 15818 vues
 |
Réponse #61 |
|
| Par orioN_^ - 25/02/2015 14:26:40 |
|
Du coup si tu veux pas avoir de problèmes de synchro en tick128, il te faut au moins 128fps calculés par ta bécane pour pouvoir envoyer des infos exactes. Sinon ton client va rien pouvoir envoyer de nouveau entre 2 tick vu que ta bécane n'a pas encore calculé l'image du tick suivant (si t'as moins de 128fps). ce qui n'empêche pas de jouer en tick128 avec 100fps, mais du coup, en plus du serveur qui peut parfois oublier tes infos d'un tick à l'autre, ton PC en rajoute une couche et n'envoie acune mise à jour pendant plusieurs tick. N'empêche que t'envoies toujours plus d'informations si ton pc envoie 100 fps et le serveur se rafraîchi 128x par secondes que si t'as 30'000 fps client et un tick64, non ? Donc ça reste préférable ? :( Je sais pas ce qui se passe pour les éventuels 28 ticks "à blanc" mais j'imagine que le serveur les prédit, d'ou les commande d'interpolation. Par contre, mais je peux me tromper totalement, on parle de fps coté client en rapport avec le tickrate du serveur, est-ce bien correct ? Les fps impliquent un calcul graphique quand même "lent" qui impliquent des éléments qui n'existent QUE pour le client (ragdolls). Donc les informations envoyées au serveurs sont des infos brutes avant traitement graphique, et donc mises-à-jour bien plus rapidement que ce que la CG envoie sur l'écran ? Ca me paraît juste hallucinant de ne pas pouvoir envoyer ces informations plus rapidement que 128 fois par secondes (128 Hz...) J'ai éventuellement rien compris, éclairez moi, plz... ^^' |
|
Réponse #62 |
|
| Par ritchauv - 25/02/2015 15:56:06 |
|
le 128 sa touche et tu met des tetes. le 64 sa touche pas et tu tire a coté. Point. xD |
|
Réponse #63 |
|
| Par Haystack - 25/02/2015 16:37:00 - Modifié le 25/02/2015 16:48:40 |
|
N'empêche que t'envoies toujours plus d'informations si ton pc envoie 100 fps et le serveur se rafraîchi 128x par secondes que si t'as 30'000 fps client et un tick64, non ? Donc ça reste préférable ? :( Je sais pas ce qui se passe pour les éventuels 28 ticks "à blanc" mais j'imagine que le serveur les prédit, d'ou les commande d'interpolation. Oui tu envoies plus d'infos en tick128 avec 100fps. Donc c'est préférable en terme d'écart client/server. Simplement si t'as 100fps et qu'un autre a 300 fps sur un tick64, tout le monde est sur le même pied d'égalité. Tandis que dans l'autre cas, le mec qui a 300 peut être légèrement avantagé en tick128. Pour les tick à blanc, simplement les infos dont a besoin le serveur ne sont pas mis à jour (position de ton viseur, position de ton personnage, orientation de ton personnage, si t'as tiré, etc...), de la même manière qu'elles ne sont pas mis à jour chez toi sur ton PC, donc il ne reste que l'interpolation. Si t'était en train de spray, tu tires toujours ce qui peut donner un kill ? [color=red]Après l'interpolation serveur, je n'y connais rien, faut être franc.[/color] Par contre, mais je peux me tromper totalement, on parle de fps coté client en rapport avec le tickrate du serveur, est-ce bien correct ? Oui tout à fait. Les fps impliquent un calcul graphique quand même "lent" qui impliquent des éléments qui n'existent QUE pour le client (ragdolls). Donc les informations envoyées au serveurs sont des infos brutes avant traitement graphique, et donc mises-à-jour bien plus rapidement que ce que la CG envoie sur l'écran ? Ca me paraît juste hallucinant de ne pas pouvoir envoyer ces informations plus rapidement que 128 fois par secondes (128 Hz...) Bah si tu veux, comme ta CG ne connais pas l'image qui suit, pour le truc qui tourne en fond et qui envoie les ticks au serveur, tu ne t'es pas encore déplacé, t'as pas encore tiré, etc. T'as rien fait vu que ton PC n'a pas les fps. Donc il ne peut pas inventer ce que va rendre ta carte graphique. Je pense tout simplement que dans le cas de CSGO (et peut être tous les jeux ?), le moteur de jeu et le réseau sont étroitement liés au rendu graphique. Entre 2 images, le moteur du jeu n'a pas connaissance des interpolations possibles. Il attend l'image pour mettre à jour la position et les actions, etc...Dans un lag graphique, tes inputs tu peux te les mettre au *** C'est ce que je pense, après je ne suis pas expert |
|
Réponse #64 |
|
| Par Haystack - 25/02/2015 16:43:12 - Modifié le 25/02/2015 16:46:35 |
|
|
le 128 sa touche et tu met des tetes. le 64 sa touche pas et tu tire a coté. Point. xD Ouai mais fais le test sur un serveur tick128 à Roubaix de le passer en tick64. Je pense que ça touchera beaucoup mieux qu'en matchmaking. Il y la congestion réseau et les paquets perdus qui ne s'affichent pas dans le net_graph, le ping, le serveur qui ignore tout un tas de choses parce qu'il doit rendre 64 ticks par seconde et qu'il a pas le temps. Un mauvais serveur, il s'en bas les steaks des détails. Il doit tourner à un tickrate constant. C'est exactement comme quand tu stream sur twitch avec un bitrate de 1000kbps et que ton rendu graphique demande 2000kbps pour être propre. Il ignore tout un tas de détails et passent à la frame suivante, parce que t'as mis 60fps sur ton stream et qu'il doit se débrouiller pour rendre 60 images par seconde avec ton bitrate pourri. Là c'est pareil. [color=red]Si le serveura pas le temps de tout traiter, il passe au tick suivant en oubliant tout un tas de détails (balle perdue?). [/color] C'est le problème des serveurs en matchmaking en plus du tickrate je pense. |
|
Réponse #65 |
|
| Par scylk - 25/02/2015 17:27:57 |
|
@Haystack "Le tickrate, c'est bien le nombre d'informations transmises par seconde." Désolé mais en soi c'est faux :s Soyons précis: Le nombre d'infos/secondes client > serveur est fixé par le cmdrate du client Le nombre d'infos/secondes serveur > client est fixé par l'updaterate du client Très logiquement, ces deux variables sont limitées par le nombre de rendus/seconde que fait le serveur, le tickrate. J'ai regardé les premières minutes de la vidéo et il fait la même simplification que toi... Si tu comprends l'anglais à mon avis le top c'est le networking guide de Valve que j'ai posté :p @Orion Le moteur d'un jeu c'est un tout, t'as pas une partie graphique indépendante de tout le reste. Quand tu fais tourner un jeu à X fps, c'est l'intégralité du jeu qui est rendue X fois par seconde. Il y a des jeux ou les fps influent sur la physique, genre cod4 ^^ |
|
Réponse #66 |
|
| Par Haystack - 25/02/2015 17:58:43 - Modifié le 25/02/2015 18:01:34 |
|
|
@Haystack "Le tickrate, c'est bien le nombre d'informations transmises par seconde." Désolé mais en soi c'est faux :s Soyons précis: Le nombre d'infos/secondes client > serveur est fixé par le cmdrate du client Le nombre d'infos/secondes serveur > client est fixé par l'updaterate du client Très logiquement, ces deux variables sont limitées par le nombre de rendus/seconde que fait le serveur, le tickrate. Je vois vraiment pas ce que ça change comme précision étant donné que ces 2 commandes sont à la valeur 64 en tickrate64 et 128 en tickrate128 (de préférence). Donc c'est bien de vouloir être précis, mais là, ça n'apporte rien. Ce qui est dit dans la vidéo est vulgarisé. Faut pas confondre quelque chose de vulgarisé avec quelque chose de complètement faux... |
|
Réponse #67 |
|
| Par Haystack - 25/02/2015 17:59:41 - Modifié le 25/02/2015 18:00:15 |
|
|
Le moteur d'un jeu c'est un tout, t'as pas une partie graphique indépendante de tout le reste. Quand tu fais tourner un jeu à X fps, c'est l'intégralité du jeu qui est rendue X fois par seconde. Il y a des jeux ou les fps influent sur la physique, genre cod4 ^^ Et sinon tu confirmes ce que je suppose dans mon dernier paragraphe de ma réponse à Orion. |
|
Réponse #68 |
|
| Par orioN_^ - 26/02/2015 08:32:47 - Modifié le 26/02/2015 08:33:35 |
|
|
@Orion Le moteur d'un jeu c'est un tout, t'as pas une partie graphique indépendante de tout le reste. Quand tu fais tourner un jeu à X fps, c'est l'intégralité du jeu qui est rendue X fois par seconde. Il y a des jeux ou les fps influent sur la physique, genre cod4 ^^ Excuse moi, mais cette affirmation me parait fausse. L'existence mêmes des ragdolls qui diffèrent entre chaques clients connectés au même serveur en est la preuve. Ton PC n'envoie pas l'intégralité de toutes les informations calculées au serveur. D'ailleurs ton lien du Networking Guide va dans ce sens: Game data is compressed using delta compression to reduce network load. That means the server doesn't send a full world snapshot each time, but rather only changes (a delta snapshot) that happened since the last acknowledged update. With each packet sent between the client and server, acknowledge numbers are attached to keep track of their data flow. Usually full (non-delta) snapshots are only sent when a game starts or a client suffers from heavy packet loss for a couple of seconds. Clients can request a full snapshot manually with the cl_fullupdate command. Ici ils disent bien que le serveur n'envoie que les informations pertinentes au client et pas l'intégralité du tick à chaque fois. Logiquement, il se passe la même chose dans l'autre sens. De plus, les informations envoyées au serveur ne sont pas graphiques, ce ne sont que des coordonées, vitesses, accélérations, angles, etc... Ca serait peu judicieux d'attendre le rendu graphique (qui diffère entre chaque client) pour update les informations sur le serveur. Je dis "peu judicieux" compte tenu de mes maigres connaissances, hein. Y a peut-être des trucs qui m'échappent. |
|
Réponse #69 |
|
| Par scylk - 26/02/2015 09:08:23 |
|
|
@Haystack Ben ça change que la fréquence des échanges d'infos est fixée par le client, dans la limite de ce que permet le serveur. Libre à toi de n'y voir qu'un détail, n'empêche qu'affirmer "le tickrate c'est le nombre d'infos transmises par seconde" ben c'est incorrect. @orion "Ton PC n'envoie pas l'intégralité de toutes les informations calculées au serveur." Euh j'ai absolument jamais dit ça. J'ai beau relire je vois vraiment pas ce qu'il y a d'incompréhensible dans mon message précédent. Ca n'a aucun sens de dire "ne pas attendre le rendu graphique pour update les infos". Je te dis que l'ensemble de ton jeu tourne à X fps. Tes infos évoluent au rythme de tes fps. T'as pas de nouvelles infos tant que t'as pas de nouvelle frame. C'est bien pour ça qu'il y a une relation entre tickrate et fps et que l'explication de valve a du sens. (Après savoir si elle est sincère ou non, justifiée ou non c'est un autre débat, je rejoins Haystack sur le fait que c'est pas le seul facteur de qualité d'un serveur.) |
|
Réponse #70 |
|
| Par Bloodman - 26/02/2015 09:24:10 - Modifié le 26/02/2015 09:24:36 |
|
Si les serveurs MM validaient déjà 100% des tirs effectués, on sentirait une énorme différence, tick 64 ou pas. Le problème principal du MM c'est la charge des serveurs. Les machines sont complètement surchargées d'où le fait que quand tu tires, tu vois du sang jaillir de l'adversaire et tu es certain de l'avoir touché au moins 2 ou 3 fois et en fait non, tu l'as juste effleuré avec une seule balle d'après le serveur. Après, à charge équivalente, le tick 128 est évidemment bien plus agréable à jouer (grosse sensation de "ça touche !"). Y'a qu'à essayer un serveur faceit ou ESEA pour s'en rendre compte puis retourner sur un serveur MM ensuite... Dans tous les cas, tant que le jeu cartonne, Valve n'a aucune raison de faire quoi que ce soit à ce niveau (achat de serveur, achat de bande passante, etc.). Ils ont probablement un plan d'amortissement de leurs serveurs et tant que celui-ci ne sera pas atteint (ou que la situation du jeu sera critique, ce qui est loin d'arriver puisqu'on est en plein essor), rien ne sera fait. Entraînez vous à aimer les serveurs MM donc. |
| Streams |
PGL
|
23827 viewers | |
ScreaM
|
4433 viewers | |
krL
|
2232 viewers | |
Zeus
|
2196 viewers | |
olofmeister
|
2073 viewers | |
|
MGG
|
939 viewers | |
|
shox
|
190 viewers | |
|
aunni
|
45 viewers | |
|
BeHop
|
29 viewers | |
|
ESWC PGW Open
|
G2 Esports 
Ninjas in Py. 
