Je suis en train de faire un jeu de type pong en réseau et je suis confronté a un putain de pb...
Pour la partie réseau, je ne sais pas trop comment procéder : j'ai des pb de synchronisation entre pc. Le jeu ne tourne pas a la meme vitesse sur des pc tres differents (ex : P200 et PII 450) et ca gene enormement : la balle par exemple ne se trouve pas a la meme position à un instant donné... Comment synchroniser tout ca ???
Sinon j'ai des truc bizarre sou nt4.

Allez vous avez bien une petite idée.
Comment ils font pour quake par exemple, quelque soit la machine la synchronisation est bonne?
Qu'est-ce qui est transmis au serveur? les clients s'occupent de quoi. Sinon j'arrive à calculer le nombre de fps pour chaque jeu donc je peux peut être faire un truc avec.

Le première chose c'est de rendre le jeu independant de la vitesse de l'ordi. Pour ca il faut que tu utilise une horloge, soit interne (le + simple) soit donnée par le serveur (ca evite les trucs genre speedhack).
 
Ensuite il te faut une architecture client/serveur: le serveur (et un seul) gère tout les joueurs (position etc...). Il recoit les inputs des joueurs et met a jours leur états, il renvoie ensuite l'info pour que le client affiche. Tu vois la le premier pb: la latence, que l'on peu compenser (ala HL).
 
N'oublie pas de travailler en UDP et pas en TCP, car TCP gère les pertes de packets avec un timeout très long, or toi il ne faut absolument pas que tu puisse etre bloqué. Donc tes packets doivent etre indepedants les uns des autres (vis a vis de la perte et/ou de la réception en ordre qqconque).

Pour le moment, ce qu'on a fait c'est que le client et le serveur tournent (cad, que le jeu avance). Le serveur se contente a intervalle régulier d'envoyer les positions des objets au client. Ce dernier ecrase alors les positions qu'il a (les objets sautent alors d'un coup si l'ecart entre les 2 est trop grand).
J'ai essayé la méthode suivante, mais c'est un peu extrème : le serveur envoie les données. Le client les recoit et rafraichit quand ils les a toutes recues. ca marche, mais ca saccade enormement et le temps de pause entre chaque envoi doit etre tres court (10 - 30 ms) ce qui fait un traffic enorme sur le reseau.

Mais t'envoies quoi comme données ?
Même si il y a 30-50 envois par seconde, ça devrait pas faire un trafiic immense.
Les 2 jeux tournent-t-ils à la même vitesse sur les 2 machines, sans le réseau ?

1- Diminue au max les donnees (représentation au plus juste, voire une forme de compression, mais attention a la latence).
2- Utilise une forme de prédiction linéaire (surtout pour un mouvement) entre deux updates au lieu de mettre a jour brusquement
3- ajuste la vitesse entre le serveur et le client avec des acks de la part du client (et un timeout prédictif).

Je bosse avec roswell sur ce projet.  
Verdoux : on envoie environ 1600 paquets par secondes (au max), et ils font chacun de 20 à 25 caractères de long. C'est rien du tout pour un réseau local, mais pour un modem, ca commence a faire.Mais bon, a la rigueur, le modem, on laisse tomber.
 
MC : en fait, c'est ce qu'on fait en ce moment. Le client continue d'avancer de son cote, mais a sa propore vitesse (et c'est ca qui fait chier.) Il anticipe donc les positions des balles, mais si le pc est plus lent que le serveur, il prend quand meme du retard. *Je vais essayer de diminuer les donnees pour voir ce que ca change.

Je pense qu'il faut une base de temps à peu près indépendante de la machine comme ça il y aura qu'une légère synchro à faire avec le réseau.

Yep, au lieu d'utiliser le framerate comme ref, il vaut mieux se synchroniser sur l'horloge interne du pc.
 
Tu fais le rendu d'une trame, puis tu prend le temps passé et tu update tout tes etats. Ensuite tu peux de nouveau rendre une trame. Si jamais le temps de rendu de la trame est trop petit devant la résolution de l'horloge tu ne fais rien. Il faut bien sur que la gestion du rendu soit dissocié de la gestion des etats.

Je pense que le maitre mot de votre programme devrais étre prédiction car 1600 envois par seconde des deux côtés c'est énorme;
Je te conseille de marshall(is)er toutes les informations concernant la trajectoire de la balle dans tes paquets et ainsi de réduire le nombre de paquets par seconde car je pense pour que ce soit fluide il suffit de 40 paquets par secondes et d'une synchronisation par horloge interne des deux côtés mais avec une tolérence du côté serveur genre qu'il soit capable d'encaisser le manque d'une trâme(et pour ca il faut que le serveur puisse prédire la position de la balle et même corriger le client en cas d'érreure).
Enfin la réduction du traffique vois sera salutaire car 1600 paquets:seconde*2machines sur une ligne 10Mbits en 10 Base T ça doit collisionner à mort!

Je vais essayer ce que propose Versoux et MC, a savoir, dissocier l'update des objets (qui prend peu de temps) et l'affichage. Verdict demain soir. Normalement, ca devrait marcher, putain, j'y avais pas pensé.
 
Au fait, on envoie que 1600 paquets dans un seul sens. Il y a tres peu de données qui vont dans le sens client -> serveur (position de la raquette, et messages de chat).
On va voir.
merci a tous.