Raydium 3D Game Engine

Donc, pendant ces 2 jours et 2 nuits, il y'a eu pas mal de choses écrites, et notre test4.c fonctionne donc en réseau AVEC la physique !
Le principe est le suivant:
- ligne UDP, paquets de taille fixe (1024 octets, y compris 4 octets d'entête)
- Le serveur (dédié et placé sur une autre machine du réseau pour nos tests) "broadcast" à l'ensemble se ses client les postions de tout le monde à une fréquence de 40 Hz.
- Un client, dès qu'il reçoit un broadcast prépare de suite un paquet contenant sa propre postion, et l'envoi au serveur (qui s'en servira pour son prochain broadcast).
- Les "postions" représentent en fait (pour l'instant) 7 doubles (1 double = 2 float) par joueur, soit un total (encore trop important) de 56 octets par joueur et par position (3 double pour les positions x, y et z et 4 float pour le quaternion de rotation).
- Le serveur actuel supporte 16 joueurs, et le seul impact sur les performances est une perte de FPS due au nombre important de véhicules à afficher !
- Le code UDP utilisé pour l'instant n'est pas capable de détecter les "ruptures" de ligne (déco du client ou du serveur) et donc pendant nos parties il est apparu au fur et à mesure du temps de nombreux "ghost".. ce qui n'est pas sans intérêt
- Le principe client du: "je n'envoi qu'après avoir recu qq chose" permet au trafic réseau de se moduler seul et évite donc les engorgements automatiquement !
- Je vais pour l'instant me concentrer sur la réduction du trafic réseau (utilisation de float et non de doubles) et essayer de me documenter pour détecter les "déconnections UDP sur sockets non bloquantes".

Il faudrait aussi organiser qq tests réseau au travers du net pour voir comment se comporte le code réseau actuel !

Je suis partant pour faire des tests quand tu veux Xfennec.

Hop ! passage des doubles aux floats: trafic divisé par deux ! (paquets de 512 octets au lieu de 1024 !)
On va attendre que tlm soit opérationnel pour faire qq tests avec cette nouvelle version

Ces tests ont eu lieu hier soir, donc, et voici les conclusions:
512 octets par personnes, c'est trop pour héberger correctement un serveur sur une ligne ADSL 512/128 .. donc après pas mal de bricolage, nous avons réduit le serveur à 3 joueurs (nous étions 3, donc ) au lieu de 16, pour une réduction à 100 octets par joueur par position, nous tombions à 2 Ko/sec par joueur et avec un serveur à 20 broadcast par secondes ! Résultat, un truc totalement fluide et régulier franchement, je m'attendais pas à un résultat pareil
Il faut maintenant gérer très vite cette histoire de déconnections UDP parce que pour l'instant, faut bien organiser le truc pour que personne ne se fasse jeter en dehors de la piste (et vu le niveau, c'est pas facile) car pas de reconnexion possible

Avoir une connexion TCP en parallèle qui sert juste à savoir si le client est toujours là ou pas, je vois pas comment faire autrement, car le protocole UDP est par définition un protocole déconnecté.

Donc il faut du TCP, (ou de l'ICMP ? un ping du client pour dire au seveur qu'il est toujours là ?)

Je pense qu'ouvrir une connexion TCP par client est supportable par le serveur, ça prend pas de bande passante (juste un PING/PONG de temps en temps pour pas que la connexion TCP timeoute comme une conne).

What do you en pense de this ?

yop
tu dis que ce que tu transmets concernant les informations du joueur est trop gros (56 octets). tu dis aussi que tu utilises 3 floats pour la position (x,y,z), ce qui est normal, et je fais pareil
mais pour la rotation, du dis 4 doubles pour les quaternions.
j'ai pas encore vraiment etudier les quaternions, mais pour placer un objet correctement (placement + orientation), tu peux utiliser trois floats : angle_x, angle_y et angle_z qui sont en fait les angles fait par le joueur avec l'axe X, l'axe Y et l'axe Z (si on considere que l'axe Z va de bas en haut, l'axe X de gauche a droite et l'axe Y de l'ecran vers le fond)
ca fait donc 3 floats au lieu de 8
mais je sais pas si c'est suffisant pour ce que tu veux faire. c'etait juste une idee

bonne continuation, et bravo pour le boulot deja realise !
++
sam

_________________
--
http://www.nova-mag.org
http://bulix.org

Oups
J'avais un peu laissé le topic à l'abandon
Yoltie: entre temps, la situation à évolué et la version 0.3 gère les décos, tout simplement par un système de timeout. Mon prb pour l'instant n'est pas que je puisse perdre des paquets, mais bien que la pile TCP/IP de Linux ne soit pas assez sympa pour me renvoyer les erreurs ICMP qu'elle recoit alors que le port est fermé à l'autre bout... Donc quand le client se déco, la "socket" UDP du serveur ne me le dit pas (alors qu'il possède tt les infos pour le faire, le rustre ) (comportement de Linux dirigé par la RFC1122 qui génére pas mal de guerres entre BSDiens et Linuxiens sur les news, semble t'il ) ... donc pour jouer la carte UDP jusqu'au bout, je laisse Raydium lui même s'occuper des décos, par un systeme tout simple de timeout.
Les tests depuis ont montrés que ca marche plutot tres bien
Cependant, tu (Yoltie) met le doigt sur un autre prb, c'est en effet celui de la non fiabilité d'une socket UDP.. là on a 2 solutions: faire les controles nous même (je penche plutot pour ca) ou utiliser un cannal TCP sur le même port.
Pour référence, bcp de jeux s'en tirent très bien avec un seul port UDP, en particulier Q3 dont on connais les perfs réseau , et je pense que ca risque de simplifier pas mal l'opération. A tester, tout simplement (N'hésites pas à te pencher sur le code de network.c, Yoltie )
sam, En effet, avant l'adoption d'ODE, nous utilisions 3 angles pour représenter une rotation dans l'espace.. ODE bosse avec des matrices de 4x3 pour faire la même chose (je ne doute pas qu'il ai de tres bonnes raisons de le faire ) qui peuvent être simplement simplifiées en quaternions (4 floats).
Le prb de la méthode des 3 angles est qu'elle va renvoyer une rotation différente en fonction de l'ordre dans lequel sont faites les rotations ("gimbal-lock" disent les gens qui connaissent (c pas mon cas ) ).. alors dans le doute et l'urgence, j'ai préféré faire confiance à des mathématiciens et perdre 4 octets.. mais j'avoue qu'un jour, je tenterais à nouveau d'utiliser les matrices, et le fait que tu en parle me laisse penser que cette idée était ptet pas si idiote que ca