[Projet la relance] 18 Distribution de travail !!

Voir le profil Envoyer un message privé SEB	Posté le 09 Août 2011 à 20:42
Messages : 554 GCPoints : 103313	Bon comme nous l'avons dit le suivi des travaux a faire et des bugs seront évidemment rescencés dans le issue tracker sur google code. Cependant il sera bien je pense d'avoir ce sujet ci destiné à manager un peu moins formellement tout ceci. Et également donner des explications sur les travaux a effectuer etc... et annoncer sa 'candidature' sur tel ou tel tache. Je pense que nous avons suffisamment d'éléments pour commencer à avancer sur les éléments qui formeront le socle de l'application et qui en soient ne font pas réellement parti du système mais que nous devons absolument avoir avant de commencer. Voila donc une liste des toutes premières taches à effectuer que vous retrouverez dans le tracker. Il suffit de se présenter comme volontaire et moi ou nepser créeront une branche portant le nom de la tache. Branche dans laquelle le volontaire sera chargé de travailler. Et lorsqu'il considèrera que le travail est fini, de le signaler à moi ou nepser qui nous chargeront de l'intégrer dans le trunk. Fichier de config, types de base, defines *fait* [cette tache est bloquante pour les suivantes] Il s'agira ici de créer un fichier nommé par exemple Base.h qui sera chargé de définir tous les types de bases de façon à ce que nous utilisions des noms de types explicites exemple : typedef unsigned int uint32; Je viens de réaliser qu'il faut se mettre d'accord d’ailleurs par rapport à ce nommage !!! Parcequ'une fois qu'il sera fait ce sera un peu tard. Personnellement je propose quelque-chose comme : sint8, uint8, sint16, uint16, sint32, uint32, sint64, uint64, float32, float64. Cette tache consistera également à surdéfinir (soit par une classe soit simplement avec un typedef les std::vector en Vector, les std::map en Map, et les std::string en String. De manière à ce que la convention que nous avons donné disant que les Classes ont des noms qui commencent par une majuscule soit respecté et également de manière à ce que nous n'ayons pas à écrire en permanence std::. A cet égar j'aurais une préférence pour une surcharge sous forme de classe de manière à ce que les choses du type 'push_back' soit surchargé en 'pushBack' également pour respecter une unité de convention. Système de log, debug *fait* Le graphe UML présent dans le sujet qui lui est destiné représente globalement quatres classes destiné à la gestion des logs dans nôtre jeux. Cette tache aura pour mission d'implémenter ces classes et également de fournir 3 macros les plus naturelle possible pour logger tout en donnant la possibilité de ne pas compiler les logs en version release. Il aura également pour mission d'intégrer la gestion des assert (macros, mode debug etc...). Les classes seront chacune dans un fichier qui leur est propre quand aux macros et assert ils devront se trouver dans un fichier nommé Debug.h qui devra ensuite etre inclu par le fichier Base.h Threads, mutex, variables conditionnelles et thread safe *fait* Cette tache consistera tout simplement comme son nom l'indique à créer les classes de thread, mutex et variables conditionelles (attention plateforme spécifique !!). Cette tache aura également pour mission ensuite d'implémenter une file de priorité thread safe cappable de se mettre a jour progressivement au fur et a mesure de l'évolution des valeurs. Classe de machine a etat Il sera également possible dans le contexte de l'initialisation de travailler également sur un élément qui sera le premier à être utilisé dans le système du jeux c'est à dire la classe de machine à état structurée. A vos candidatures, je vais de ce pas remplir le issue tracker avec tout ceci. Dernière édition le 11 Août 2011 à 16:29 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 09 Août 2011 à 22:52
Messages : 4017 GCPoints : 347288	Pour les types, Irrlicht propose déjà ce genre de nommage: http://irrlicht.sourceforge.net/docu/irr_types_8h_source.html Je propose de l'utiliser, il est simple et intuitif.
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 00:15
Messages : 554 GCPoints : 103313	J'aime bien un équivalent avec 'int' et float dans le nom. Ca me stresse des noms de type en deux caractère XD. Et par contre je suis contre le fait d'utiliser ceux de irrlicht comme types natif au jeux (meme si ce n'est pas ca que tu sous entendais je préfère le dire :p) et je n'aime pas trop car ils sont dans un namespace et que ce n'est pas très pratique. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 10 Août 2011 à 19:23
Messages : 4017 GCPoints : 347288	C'est la solution de facilité, et un 'irr::' devant les noms de type n'est pas très contraignant. Faudra attendre l'avis des autres ;) Pour les chaines de caractères, j'ai une autre question: unicode ou pas ?
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 19:37
Messages : 554 GCPoints : 103313	Pourquoi c'est la solution de facilité? ^^ je ne comprend pas bien ce qui est plus facile au niveau des types? Ca effectivement c'est la grande question au niveau des chaines. Mais je pense que c'est pour cette raison qu'il est nécessaire d'avoir une classe de string de manière à ce qu'on puisse changer d'avis sur ce sujet sans avoir à se poser trop de problèmes. Quoi qu'il en soit je pense qu'il faut que ce soit uniforme si on utilise du unicode on utilise du unicode partout et inversement. Ah et je ne sais pas si je l'ai dit. (il me semble pourant que oui) Mais ce sujet attend des candidatures ^^ ! Les deux premiers travaux sont déja terminés et testés sous Windows Vc++, Mingw et sur Linux Gcc. Et les deux suivants ne sont pas énormes non plus donc si des volontaires se présente ca serait pas mal ^^ ! Dernière édition le 10 Août 2011 à 20:15 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 10 Août 2011 à 20:47
Messages : 116 GCPoints : 23144	Je doute de l'utilité, et je trouve ça même pas super cette idée de typedef partout. Si on utilise l'existant, je préfère toujours l'avoir en tant que tel. C'est un objet externe, alors je l'utilise comme il existe. Et surtout, par pitié, pas de using.... A la limite, un typedef pour chaque classe spécifiquement, mais pas de surcharge... Je ne vois pas trop l'intérêt de faire du threading à l'heure actuelle aussi... Tu veux threader quoi?
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 21:04
Messages : 554 GCPoints : 103313	Citation : Je doute de l'utilité, et je trouve ça même pas super cette idée de typedef partout Comment ca partout? L'idée c'est d'avoir un fichier central qui définit des types de base (sans namespace) de facon à ce que le typage soit clair quand à l'espace mémoire qu'il occupe et qu'on ai pas à se taper des 'unsigned' partout car c'est super chiant. Mais le mieux peut-etre c'est d'updater et de regarder le fichier Base.h que j'ai envoyé sur le repository. Tu verra qu'il n'y a pas des typedef partout les noms de types sont uniformes et cela ne requiert pas de usigng namespace (car je suis aussi complètement anti using namespace). Citation : A la limite, un typedef pour chaque classe spécifiquement, mais pas de surcharge... Ok j'aurais du employer le bon mot 'Surcouche'. Citation : Je ne vois pas trop l'intérêt de faire du threading à l'heure actuelle aussi... Tu veux threader quoi? Le chargement des elements graphiques du level.... pour qu'on puisse avoir quelquechose qui apparait le plus vite possible.. qu'on ai un temps de chargement quasi nul et qu'on économise la mémoire. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 10 Août 2011 à 21:59
Messages : 116 GCPoints : 23144	~~Un peu hors sujet, mais... pas de fichier "config.cmake" dans le projet?~~ Désolé problème d'habitude... Pour les surcouches, on perds quand même pas mal d'outils comme les allocator de la STL. Tu vas t'amuser à surcoucher aussi les queue/set/multimap et autres? Tu veux aussi faire ça pour les classes irr:: ?? Threader apportera plus de problèmes qu'autre chose dans un premier temps => il est plus intéressant de faire un chargement de niveau entier, faire jouer le personnage dessus puis enfin se poser le problème de threading, le mettre en place de façon efficace n'est pas forcément évident. Dernière édition le 10 Août 2011 à 22:02
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 22:12
Messages : 554 GCPoints : 103313	Pas de problème ^^ le fichier de config.cmake doit etre créé par chacun ^^ ! Car chacun a son envi donc sa config ^^ Il suffit de mettre ensuite dedan la ligne set(CPP_COMPILER "vsc") si vous utilisez visual ou set(CPP_COMPILER "mingw") si vous utilisez codeblocks. Honètement perdre les allocateurs de la stl ne me chagrine pas franchement plus que ca XD quels allocateurs std pourraient nous intéresser d'ailleur ? Quand à surcoucher les queue, set, multimap je suis pour si jamais on vient à avoir l'utilité d'un de ces éléments. Non je ne veux pas le faire pour les classes Irr mais c'est un peut différent dans le sens ou irrlicht est clairement une librairie externe. Or des collections comme les Vector, Map et également les String on en aura besoin tout le temps et ce n'est pas une lib. Je me demande pourquoi à l'heure des 8 coeurs on est encore si frilleux à utiliser des threads... il n'y a franchement rien de compliqué dans les threads... c'est certain que ca posera disons... 20% de problèmes en plus initialement. Sauf que je connais trop bien les 'on verra ca plus tard'. Quand on a avancé il est souvent bien trop tard pour revenir en arrière sans mettre un énorme coup de pied dans la structure. Donc non je maintien qu'il faut y penser et le faire le plus tôt possible quand on y sera. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 10 Août 2011 à 22:29
Messages : 116 GCPoints : 23144	Parce-qu'un thread n'est pas lancé sur un cœur différent ^^. Après je vois pas trop l'intérêt de débattre de l'intérêt, le tout c'est que tu prennes en compte le risque et les problèmes liés pour arriver enfin à un résultat. Je suppose que tu l'auras compris, je suis un gros utilisateur de la STL, donc je viendrais t'emmerder si j'ai pas exactement ce dont j'ai besoin :p
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 22:51
Messages : 554 GCPoints : 103313	Citation : Parce-qu'un thread n'est pas lancé sur un cœur différent ^^ Je peux savoir d'ou tu tiens tes sources? Franchement je serais sur le c** si tu m'apprennai que les thread ne tirent pas partie du multi core.... et de savoir comment tu explique le 100% lorsque je lance 8 thread a donf sur un 8 coeur alors que je n'ai que 25% lorsque j'en lance 2.... ? C'est sur que sur une machine mono coeur ca n'a pas d'influence... mais la n'est pas la question. Pour la stl il n'y a pas de problèmes :p je citerais simplement un sketch de Colluche je crois : dis moi ce dont tu auras besoin et je t'expliquerais comment t'en passer :p (et au cas ou je ne sais pas te répondre avec une efficacité quasi équivalente en 'temps/performances' je me résoudrais à intégrer la fonctionnalité ^^ !!) Dernière édition le 10 Août 2011 à 22:53 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 10 Août 2011 à 23:16
Messages : 116 GCPoints : 23144	Un thread doit partager pas mal de chose avec son processus en particulier un espace mémoire. On est d'accord pour dire que sur un coeur "ça ne pose pas de problème" car chaque thread l'un après l'autre va exécuter ses opérations (le problème réside dans la synchronisation des informations, donc ce n'est pas un problème matériel) Par contre, 2 cœurs n'ont rien à voir entre eux, en particulier ils peuvent exécuter une opération au même moment; et si tu permets aux 2 d'écrire au même endroit au même moment... il se passe quoi? Et ici la réponse ne peut pas être mutex ou sémaphore puisque ça reste une variable en mémoire. Maintenant, ça reste peut-être un problème qui a été résolut depuis que j'ai appris ce fonctionnement; je vais investiguer.
Voir le profil Envoyer un message privé SEB	Posté le 11 Août 2011 à 09:42
Messages : 554 GCPoints : 103313	Heu oui je ne sais pas... je suis d'accord qu'un thread partage pas mal de choses avec son processus. A savoir l'espace mémoire 'heap' et il possède sa propre pile. Après pour le partage des pages de codes je ne sais pas trop comment ca marche mais ca ne doit pas poser énormément de problèmes puisque ce n'est que de la lecture. Donc effectivement sur un coeur ca va. Sur deux, effectivement il ne faut pas travailler sur les mêmes élément de 'heap' en même temps. Sinon on risque les comportements indéfinis. Mais SI JUSTEMENT les sémaphore et les mutex ont été créés pour ca. Et c'est le Système d'exploitation sous-jacent qui traite cela. Lors du 'lock/unlock' d'un mutex/sémaphore il est effectivement tout à fait probable que le système d'exploitation passe par une phase 'syncrone' d'un laps de temps relativement court. Da manière à assurer l'atomicité de l'opération. Donc aucun problème avec les threads si on utilise des mutex et spinlock. (sachant que le choix entre l'un ou l'autre doit être vraiment basé sur la fréquence de conflit d'accès) Mais effectivement ca vaut le coup de vérifier plus loin ^^ NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 11 Août 2011 à 10:14
Messages : 116 GCPoints : 23144	Les locks/mutex/... sont de base obligés sur un threading mono-cœur puisque certaines opérations sur des objets peuvent être en suspend. Ils résolvent un problème logiciel. Là où je dis que c'est inutile, c'est que pour moi le problème est matériel. Après avoir un peu recherché, il est tout à fait possible d'avoir du threading sur plusieurs cœurs d'un même processus. Par contre je ne sais pas trop comment ils arrivent à ne pas créer de conflits d'utilisation de la ram. Apparemment il y a une histoire d'affinité avec les cœurs, mais ça reste flou pour moi.
Voir le profil Envoyer un message privé SEB	Posté le 11 Août 2011 à 16:33
Messages : 554 GCPoints : 103313	Un nouveau travail arrive : Creation du configuration manager et des config file Cette tache aura pour but d'implémenter le config manager et le config file il sera laissé libre aux chargé d'implémentation le choix de faire ce qu'il veut au niveau du fichier de config (organisation) Il peut tout aussi bien utiliser de l'xml (via la classe xml d'irrlicht) ou bien faire un système de "clef\|valeur" par exemple etc.... NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 11 Août 2011 à 20:47
Messages : 4017 GCPoints : 347288	Je veux bien le faire, par contre j'ai besoin de quelques renseignement sur l'utilisation du ConfigManager: sera t-il utilisé juste pour les propriétés 'globales' du jeu (genre, quelle carte graphique utiliser, quel pilote vidéo, etc...), ou aussi utilisé pour les sauvegardes (ce que personnellement je ne trouve pas super) ? Je peux faire un truc avec des macros, simple à utiliser, et qui offre une garantie sur les propriétés maniées : pas de possibilité d'utiliser une propriété qui n'existe pas (ça compilera pas sinon). Autrement dit, tout statique. Sinon je peux aussi faire en dynamique (mais c'est - je trouve - moins sûr).
Voir le profil Envoyer un message privé SEB	Posté le 11 Août 2011 à 21:02
Messages : 554 GCPoints : 103313	Ok nikel ^^ ! je vais créer la branche et t'affecter la tache dans le issue tracker d'ici 10 minutes. Pour les renseignements que tu demandes oui je te confirme que ce config manager est bien un 'config manager' et non pas un sauvegarde manager. J'aime bien l'idée que tu avais déja proposé précédemment. Et je dirais .. pourquoi pas. L'inconvénient que je verrais a cela c'est qu'il faut justement déclarer les statiques quelquepart... (meme si c'est avec une macro) et du coup. On pourrait presque faire une unique classe statique avec toute les propriétés de config et forcer les personnes à utiliser cette classe. Je trouve le système à chaine un peu plus souple (même si cela risque de donner des endroits ou l'on demande des valeurs mal nommées). Mais dans ce cas on pourrait afficher des warning pour les valeurs demandé dont les clefs n'existent pas. Bref j'ai envi de dire utilise la methode que tu trouve la mieux. On verra ensuite à l'usage. Mais dans ce cas dans la branche destinée commence par faire un micro diagramme uml avec yEd décrivant assez précisément les classes d'un système comme tu le propose. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 11 Août 2011 à 21:07
Messages : 4017 GCPoints : 347288	Ok! Je ferais le diagramme, il est relativement simple (peu de classes). Pour ce qui est de la définition des propriétés, oui faudra un fichier cpp qui contiendra toutes les définitions, ça permettra en un coup d'oeil de voir toutes les propriétés présentes. Pour l'utilisation d'une propriété non existante, en fait c'est impossible : le jeu ne compilera même pas (donc pas besoin de warning ;) ). C'est très pratique je trouve, et faut savoir que ce système (enfin, un vraiment très similaire) est utilisé dans mon éditeur de particules (SPARK). Dernière édition le 11 Août 2011 à 21:08
Voir le profil Envoyer un message privé SEB	Posté le 11 Août 2011 à 21:11
Messages : 554 GCPoints : 103313	Oui je parlais de warning dans le cas ou l'implémentation serait non statique :p Voila la branche est créée et la tache affectée à toi ! Bonne chance ^^ ! NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 12 Août 2011 à 14:55
Messages : 554 GCPoints : 103313	Une nouvelle tache annexe qui peut etre faite sans trop de souci en parallèle: Création de la version 1 du module de son: Cette tache consiste a utiliser le diagramme qui a été fait pour créer le module de son dans un premier temps tout basique. Avec ses deux classes accompagnatrices 'Sound et Music' Cette classe doit être basée sur la librairie cAudio (en include) et 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