akoutsos
commented
11 years ago Moi et Papy étions plutôt pour un un seul thread scénario/simulation. La gestion des accès concurrent est trop chiante et lente. Sinon après je pensais que la simu ne reçoit rien du réseau (toutes les actions passe par le scénario avant). Après je pensais à une boucle du type:
- scénario : récupérer les événements générés par la simulation + événements du réseau
- traiter ces événements, et générer les nouvelles actions pour la simulation
- simulation: appliquer les actions générées par le scénario
- appliquer toutes les règles d'évolution (mouvements des personnages, évolution des paramètres globaux, peur ...)
Ensuite pour ce qui est de la boucle en temps constant, je n'en vois pas l’intérêt. Le serveur doit juste travailler le plus vite possible, il n'a aucune contrainte de FPS ou quoi que ce soit.
Le 14/11/2013 17:09, mheinric a écrit :
Bon, c'est juste concernant la façon dont s'organise le code globalement, entre chaque partie. On a rien noté à ce sujet, et je pense que c'est important de se décider rapidement dessus parce que certains choix en dépendent. Donc globalement ce qu'on peut faire c'est quelque chose de plutôt linéaire, avec une boucle d'update de la forme (pour le coté serveur):
- scénario : récupérer les évenements générés par la simulation
- traiter ces évênements, et en générer des nouveaux pour la simulation
- simulation : récupérer les évênements reçus (réseau + scénario)
- les traiter
- appliquer toutes les règles d'évolution (mouvements des personnages, évolution des paramètres globaux, peur ...)
- on recommence au début, en attendant éventuellement un peu pour avoir une boucle de temps constant
L'autre solution étant de faire deux threads séparés. Un thread sur le scénario, et un sur la simulation. Le problème majeur de cela étant que ça nécessite que toute la structure de donnée de l'état local soit accessible et modifiable de façon concurrente (aucun des conteneurs fournis dans la librairie standard n'est 'thread safe'). De ce que j'ai regardé, l'utilisation de structures parallèles (mutex, type atomique de la librairie standard, ou encore un truc de la librairie boost) donnent des temps d'exécution environ 10-20 fois plus important, ça peut être problématique si il y a des besoins massifs d'accéder à l'état local. Sans compter le fait qu'on est pas certain que l'état local soit cohérent si un pas de simulation est en cours.
Et enfin (promis j'arrête), du côté client, il faut peut être aussi caser dans la boucle un bout de calcul du module graphisme pour mettre à jour la fenêtre. Qu'est ce qu'en pense les personnes concernées?
Bref, si vous avez des suggestions.... (désolé d'en avoir mis 3 tonnes)
— Reply to this email directly or view it on GitHub https://github.com/ProjetM1MPRI2013/central/issues/7.
adhusson
mheinric
Bon, c'est juste concernant la façon dont s'organise le code globalement, entre chaque partie. On a rien noté à ce sujet, et je pense que c'est important de se décider rapidement dessus parce que certains choix en dépendent. Donc globalement ce qu'on peut faire c'est quelque chose de plutôt linéaire, avec une boucle d'update de la forme (pour le coté serveur):
L'autre solution étant de faire deux threads séparés. Un thread sur le scénario, et un sur la simulation. Le problème majeur de cela étant que ça nécessite que toute la structure de donnée de l'état local soit accessible et modifiable de façon concurrente (aucun des conteneurs fournis dans la librairie standard n'est 'thread safe'). De ce que j'ai regardé, l'utilisation de structures parallèles (mutex, type atomique de la librairie standard, ou encore un truc de la librairie boost) donnent des temps d'exécution environ 10-20 fois plus important, ça peut être problématique si il y a des besoins massifs d'accéder à l'état local. Sans compter le fait qu'on est pas certain que l'état local soit cohérent si un pas de simulation est en cours.
Et enfin (promis j'arrête), du côté client, il faut peut être aussi caser dans la boucle un bout de calcul du module graphisme pour mettre à jour la fenêtre. Qu'est ce qu'en pense les personnes concernées?
Bref, si vous avez des suggestions.... (désolé d'en avoir mis 3 tonnes)