Page [1][2]

[Projet la relance] 18 Distribution de travail !!

Voir le profil Envoyer un message privé nepser	Posté le 12 Août 2011 à 15:25
Messages : 116 GCPoints : 23144	Tiens je vais m'occuper du son. Faire des jolies playlist toussa. Petite question sur l'architecture, le maxdelay, c'est le temps qui s'est écoulé depuis le dernier update?
Voir le profil Envoyer un message privé SEB	Posté le 12 Août 2011 à 15:42
Messages : 554 GCPoints : 103313	Ok je vais te l'affecter j'ai juste créé la première classe sans implémentation. Par contre tu parle de playlist ? Pour le moment il n'y a que 3 classe très simples à faire. Si playlist il doit y avoir il faudrait savoir dans quel objectif et faire le diagramme avant (comme pour Darktib). Pour ce qui est du 'maxdelay' il concerne non pas le temps depuis la derniere update mais le temps maximum alloue pour l'update du module en millisecondes. Effectivement il pourrait etre intéressant de connaitre le temps écoulé depuis la derniere frame, a ajouter au diagramme egalement. (Je t'affecte à la tache dans google) (Et n'oublie pas : "doit autant que possible essayer de se baser sur le principe d'un wrapping dynamique. (sans linkage à la compilation)") ? NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 12 Août 2011 à 16:01
Messages : 116 GCPoints : 23144	Pas de prob pour le wrapping. Je suppose qu'on est d'accord pour déléguer le rôle de lecture des musiques au soundmodule? De ce fait, on lui donne juste les "identifiants" des musiques/son à jouer ou de l'opération à effectuer dessus. Voir un poil de cul plus haut niveau effectuer des opérations sur la musique courante. L'idée derrière la playlist c'est de pouvoir dire "joue moi ces X musiques d'affilé pendant le level et fais des transitions dessus".
Voir le profil Envoyer un message privé SEB	Posté le 12 Août 2011 à 16:26
Messages : 554 GCPoints : 103313	Ok pour la playlist je vois ce que tu veux dire mais je ne voyais pas autant pousser ce premier développement du module de son. Par contre au niveau des 'identifiant' par lesquel on délegue au sound module le rôle d'appeler les méthode de sound et music... je trouve ca pas très simple. J'imaginais plus le sound module comme chargé de 'créer' les Sound et les Musique, de les 'Détruire' et également de manager quelques petits trucs comme des playlist effectivement ou des demande de transition entre deux sons ou musique. Mais je pensais laisser le soin à l'utilisateur du son/musique d'appeler 'play,loop,stop' sur son son lui même. Et d'ailleur ceci dit il serait du coup intéressant d'avoir un timer pour pouvoir savoir si on est dans les délai dans les update. Je rajoute cela au diagramme puis en tache. Dernière édition le 12 Août 2011 à 17:05 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 12 Août 2011 à 17:22
Messages : 116 GCPoints : 23144	Laisser l'utilisateur se démerder avec une liste de sons/musiques qu'il doit gérer à chaque évènement? En gros il devrait re-référencer tous les sons et leur contexte tout en prennant soin de gérer leur état? @_@ Hum non :p De toute façon je retravaillerai la conception lorsque je pourrai bosser
Voir le profil Envoyer un message privé SEB	Posté le 12 Août 2011 à 17:42
Messages : 554 GCPoints : 103313	Citation : Laisser l'utilisateur se démerder avec une liste de sons/musiques qu'il doit gérer à chaque évènement? En gros il devrait re-référencer tous les sons et leur contexte tout en prennant soin de gérer leur état? @_@ Hum non :p Franchement j'ai toujours beaucoup de mal à voir comment tu envisage les choses..... ce n'est pas un reproche mais juste un constat. Mais sérieux de Quels évènement l'utilisateur devrait il se démerder? Et surtout de quel 'liste' ??? Pourquoi il devrait re-référencer tous les sons....(et leur contexte en prime....) en gérant leur état? Franchement je pense qu'on devrait discuter plus avant de se lancer parceque j'ai vraiment du mal à suivre défois. Qu'on soit clair... dans la conception UML la classe Son et Musique ne sont pas les classe de la lib cAudio. Ce sont des 'mini surcouches'. Donc j'ai besoin d'éclaircissement par rapport à ce que tu veux dire. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 12 Août 2011 à 18:33
Messages : 116 GCPoints : 23144	Alors, le problème de laisser à l'utilisateur (je parle de l'utilisateur du module, donc un développeur) le contrôle sur les objets de musiques/sons est que ces objets vont être distribués un peu partout ensuite dans l'application alors qu'ils ont un contexte très lié. Lorsqu'on veut lancer une musique, il faut arrêter celle en cours grossièrement. Si tu laisse chaque utilisateur devoir ce genre d'évènement, il va forcément il y avoir des appels foireux => le but est de connaître un contexte global dans lequel on peut déterminer comme faire des transitions entre chaque musique son. Je veux lancer ma musique => comment arrêté ce qui est en cours? Autre chose, si on veut lier tous les sons que peut produire une entité lors d'un collision/action, il va bien falloir les stocker quelque-part, chaque objet lanceur de son va donc avoir un objet avec tous les sons qu'il peut lancer? De plus dans le même cas, comment pourrait-on appeler destroySound => si le pointeur est copié à x endroits, le soundmodule ne peut pas déterminer s'il peut détruire une ressource, elle pourrait être utilisé par un autre objet (et on a dit pas de smartptr) Encore autre chose, un objet possède une musique: Ok. La musique se termine, est-ce qu'il doit la relancer? Lancer une autre? => intérêt de la playlist. Autre chose, il faudra mettre à jour cet objet à chaque fois afin de savoir s'il doit relancer une action, alors que l'objet n'a pas forcément besoin d'être mis à jour => le flot d'exécution de l'application va partir dans tous les sens. Conclusion, avec un objet qui gère tout le contexte du son (de la même façon qu'un moteur graphique) on évite les désynchronisations d'exécution, on allège la responsabilité utilisateur, on contrôle la mémoire et le contexte.
Voir le profil Envoyer un message privé SEB	Posté le 12 Août 2011 à 20:30
Messages : 554 GCPoints : 103313	Ok déja tout est plus clair la ^^ !! Donc qu'il soient distribué.. c'est malgré tout une vue. Car si tu regarde bien le schéma qui a été fait le module sonore connait la liste de tous les sons qu'il a alloué et idem pour les musique. Donc effectivement il conserve l'ensemble des sons. Rien n’empêche de conserver un compteur des demande d'accès et release. Citation : Lorsqu'on veut lancer une musique, il faut arrêter celle en cours grossièrement Cela peut être fait en conservant le SoundModule parent dans les sons et les musiques..... Chaque objet lanceur de son n'aura pas nécessairement une liste de tous ses sons possible. Cela pourrait être géré au niveau des callbacks ou des actions. Mais même si cela devait être stoqué au niveau des entités je ne vois pas en quoi c'est si génant, si la conception est bien faite et sufisemment factorisé ca ne pose pas vraiment de problèmes. Je n'ai pas remis en cause le principe de la playliste j'ai simplement dit que la playliste ne faisait pas parti de cette première version du sound module. Mais c'est effectivement quelquechose qui sera a faire dans une seocnde version du sound module. Citation : Autre chose, il faudra mettre à jour cet objet à chaque fois afin de savoir s'il doit relancer une action, alors que l'objet n'a pas forcément besoin d'être mis à jour => le flot d'exécution de l'application va partir dans tous les sens. La de nouveau je ne te suis plus de quel objet tu parle au début de ta phrase? Oui un objet qui gère le contexte du son c'est le sound module. Qui contient la liste de tous les sons instanciés et des musique et qui gère des transitions. Mais ca n'empèche en rien aux objets de contenir directement des sons et des musiques (mini surcouche de cAudio). NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 14 Août 2011 à 16:46
Messages : 554 GCPoints : 103313	Bon je dois vous signaler que je serais absent cette semaine jusqu'au lundi 22 donc j'espère que vous pourrez bien avancer sur ces travaux. Bon courage à lundi donc ! NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 24 Août 2011 à 20:35
Messages : 554 GCPoints : 103313	De nouveaux travaux arrives : Creation des classes GameSystem et de la spécialisation GameCorpPlatformGame Ce travail consiste simplement a créer les classes et les implémentations de base de ces classes qui entameront la gestion plus concrète du jeu. RenderingModule de base Ce travail consiste à créer le module de rendu de base avec l'instanciation des structures minimales irrlicht et le lancement du device vide et la possibilité de passer en paramêtre les préférences. Engine Core Ce travail consiste à créer la base de la classe EngineCore qui instanciera et managera les différents gros modules de gestion graphique, sonore, réseau etc... NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 25 Août 2011 à 17:19
Messages : 4017 GCPoints : 347288	Tâches intéressantes - mais à cause de la rentrée, je ne pourrais pas les faire... @tout le monde: Pour ce qui est du config manager, il est utilisable dans l'état, par contre la sérialisation n'est pas encore finie. Pour l'utilisation: * Utilisez DECLARE_CONFIG_PROPERTY en haut d'un fichier source pour déclarer une propriété. C'est aussi possible dans un header mais moins propre je trouve. Cette macro ne doit pas être mise ni dans une classe, ni dans une fonction, ni dans un namespace. * Utilisez CONFIG_PROPERTY dans n'importe quelle fonction pour récupérer la valeur d'une propriété préalablement déclarée. * Après, ça ne suffit pas, il faut définir les propriétés (sinon erreur de link) : il faut un fichier source qui ne va contenir que les définitions de propriétés, via REGISTER_CONFIG_PROPERTY. Pour faire simple, il faut imaginer les propriétés comme des variables partagées par tout le programme, mais dont l'utilisation est plus sûre que pour des variables globales. Pour une aide détaillée sur les macros, cf Configuration.h (au besoin, allez voir dans la branche ConfigManager). @SEB: pour les notes que tu as faites, je te répond ici ou en mp ?
Voir le profil Envoyer un message privé SEB	Posté le 25 Août 2011 à 17:25
Messages : 554 GCPoints : 103313	Dans le meme fichier comme ca ca garde une trace ;) NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Voir le site bebou007	Posté le 25 Août 2011 à 20:42
Messages : 238 GCPoints : 43228	salut j'ai quelque question -a quoi sert le config manager? -j'ai tous configurer et crée la solution sur visual studio 2010 expresse il y a 4 projet (ALL_BUILD,GameCorpProject,Unit_Tests et ZERO_CHECK) a quoi ils servent? -c'est quoi la difference entre branches et trunk il ont les même dossier?
Voir le profil Envoyer un message privé SEB	Posté le 25 Août 2011 à 21:16
Messages : 554 GCPoints : 103313	Déja c'est bien d'avoir réussi à créer la solution. Le ConfigManager si tu parle de la 'classe' il servira à stoquer toutes les préférences générale de la personne qui utilise le jeu. Par exemple le config manager permettra de sauvegarder dans un fichier la résolution, les options sonores etc... Les 4 projets sont donc respectivement : ALL_BUILD et ZERO_CHECK sont des projet qui sont un peu a part spécifique à la génération par CMAke donc il ne faut pas trop s'en occuper. Ensuite le projet GameCorpProject est celui qui concerne le jeu final. Et le projet Unit_Tests sert à créer un executable charger de tester le fonctionnement correct de toutes les classes. Le oui les dossiers qui sont dans les branches et dans le trunk se ressemble énormément, la seule différence c'est que le trunk contient toujours la dernière version 'stable' en clair on ne développe pas dans le trunk. Chaque fonctionnalité qui nécessite d'etre développé voit une branche crée spécifiquement pour cela. Les branches sont donc les dossiers dans lesquels on 'travaille' et on développe les classes etc... NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Voir le site bebou007	Posté le 25 Août 2011 à 23:15
Messages : 238 GCPoints : 43228	donc en fait il faut faire l’étape de cmake et du fichier config.cmake sur toute les branche si on veut la solution? et si je veut par exemple travailler sur Engine Core je crée un dossier Engine Core et je met quoi dedans ? je doit mètre de projet trunk? et ajouter Engine Core? Dernière édition le 25 Août 2011 à 23:23
Voir le profil Envoyer un message privé Voir le site bebou007	Posté le 25 Août 2011 à 23:23
Messages : 238 GCPoints : 43228	désoler du double poste je sais pas pourquoi j'ai fait une citation de moi même mais on peut pas supprimer les poste Dernière édition le 25 Août 2011 à 23:33
Voir le profil Envoyer un message privé SEB	Posté le 26 Août 2011 à 09:40
Messages : 554 GCPoints : 103313	Ok pas de problème et désolé de ne pas avoir donné d'explications plus détaillées. Donc les 'étapes' se déroulent comme ca : Si tu veux 'voir' à quoi ressemble la dernière version stable, il faut que tu 'cmake' dans le dossier 'trunk/dev' cela va te générer une solution que tu devras compiler. Une fois compilée, les executables généré devrient se trouver dans le dossier 'trunk/bin'. Ensuite pour ce qui est de 'travailler' sur un élément ou l'autre, le process est le suivant. Les 'travaux a effectuer' sont annoncés ici puis référencés sur le site de google code en tant que "issue" de type "review" à traiter à l'adresse suivante http://code.google.com/p/game-corp-community-project/issues/list Si quelqu'un est intéressé par un travail il doit le signaler ICI ou par mail à Moi ou Nepser. A ce moment la (lui ou moi) créons une branche portant le nom du travail et affectons l'issue à la personne qui a fait la demande. Une fois cela fait, la personne en question peut 'updater' son repository (chose qu'il faut faire régulièrement en principe => environ une fois par jour) une fois le repository updaté, le dossier branch contiendra un dossier portant le nom du travail et étant la copie conforme de l'actuel 'trunk'. Il faudra donc que le chargé du travail refasse un cmake dans son dossier 'branches/****/dev' et qu'il ne travaille que dans celui-ci. Pendant toute la durée de ses travaux la personne est responsable d'ajouter au svn les fichiers supplémentaires et d'envoyer les modifications régulièrement. Une fois que le chargé de travaux estime avoir terminé son travail (au bout de quelques jours, semaines, mois) il doit en informer les intégrateurs à savoir Moi ou nepser qui se chargeront de jetter un coup d'oeil à ce qui a été fait, de faire éventuellement quelques remarques nécessaire, de vérifier la compatibilité windows/unix et enfin de passer le 'statut' de l'issue à 'verified' après avoir mergé les modifications dans le dossier trunk. Enfin les administrateurs supprimeront la branche de dev. Cependant les trois travaux cités précédemment sont déja terminés. Il va falloir que je crée une nouvelle liste. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 01 Sep 2011 à 18:23
Messages : 554 GCPoints : 103313	Nouveau travail : Creation states flowchart *fait* Ce travail consiste à créer toutes les classes (vides) héritant de state pour la machine a état de la flowchart de base. IntroductionState, PlayerNameState, etc... Controls handler *fait* Ce travail consiste à créer les classes chargé de 'récupérer et traduire' les touches et les différents inputs. Classes ControlsHandler, KeyboardControlsHandler, MouseControlsHandler, JoysticControlshandler, PadControlsHandler et InputActionHandler Dernière édition le 14 Nov 2011 à 14:35 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 14 Nov 2011 à 16:16
Messages : 554 GCPoints : 103313	Remplissage du state 'crédits' du main menu Ce travail consiste à remplir le state de la flowchart correspondant aux crédits (pas forcément en mettant de belles textures mais en faisant disparaitre le menu principal puis apparaitre un label avec les noms et l'adresse de game-corp. Ainsi qu'un bouton retour. Remplissage du state 'options' du main menu (v1) Ce travail consiste à remplir le state de la flowchart correspondant aux options. Il faudra peut-être gérer un niveau supplémentaire de sous-menus pour chaque catégorie. Pour le moment une catégorie son avec 'volume musique' 'volume sons' serait bien. Ainsi qu'une catégorie graphismes avec uniquement une liste des résolutions disponibles. Ce travail devra être relié au système de configuration pour que l'on puisse sauvegarder ces préférences. Remplissage du state 'nom du joueur'. Ce state arrive avant le main menu avec un champ texte, un bouton valider et la liste de tous les joueurs connus précédemment pour pouvoir en changer simplement. Il doit donc faire appel lui aussi au système de configuration pour sauvegarder ces différents noms. NextGine : 3D games engine Nombre de lignes actuel : 77683