[Projet la relance] 15 Uml, objet quand tu nous tiens !

Voir le profil Envoyer un message privé SEB	Posté le 07 Août 2011 à 16:25
Messages : 554 GCPoints : 103313	Bon pendant que tous les autres sujet évoluent je pense qu'il est également temps de se lancer dans la conception du projet. J'ai donc entamé le design objet de l'application je vous poste ici une première image. Ce n'est absolument pas complet mais 1 Je ne souhaite pas le faire moi même en enter 2 A mon avis cela va prendre un peu de temps a faire 3 Je pense qu'il y a déjà dequoi débattre. Un petit briefing par rapport à ce début de design. Tout d'abord la machine à état générique composé du StructuredFiniteStateMachine et du State. Qui nous permettra de concevoir très simplement les différentes 'pages' et zone temporelle de l'application ainsi que leur transition. Cela pourra également être utilisé pour diverses animation de GUI, pour les PNJ aussi mais je suggèrerais l'utilisation d'autre type de machine à états pour les PNJ. Donc les state sont ensuite spécialisé selon EngineInit, EngineUpdate, EngineShutdown => ce schéma représentant la machine à état de base qui sera instanciée par le main. Cette machine aura la charge d'initialiser le EngineCore selon les préférences stockées en configuration ou par défault, elle créera et fournira également l'instance de GameCorpPlateformGame qui sera l'objet updaté par le engine core entre les phase de rendu et de flush. Ce fameux game système contient comme vous le voyez également une machine a état regrouppant les états : Introduction, PlayerName, MainMenu, SelectWorld, OptionMenu, StoryMenu, SelectLevel, CreditsMenu et MultiplayerMenu. Ceci concerne donc la structure temporelle et de 'page' principale du jeux. On trouve également dans ce schéma un autre block concernant la gestion des différents types de périphériques de contrôle. Les périphériques de contrôles enverrons leurs informations directement au EngineCore et seront centralisée par celui-ci, il aura donc pour mission de les re-dispatcher aux ControlsHandler que nous lui donneront selon 4 grandes catégories (Souris, Clavier, Pads, Joystick) Cependant comme nous ne pouvons pas connaitre à l'avance l'ensemble des pads, joystick etc.... nous nous baserons sur des tables redirigeant les diverses touches sur des 'commandes jeux' la transformation de 'touche => commande jeu' sera faite par les instance de ControlHandler qui les feront suivre une fois transformé au InputActionHandler qui sera le seul intéressant pour les personnes chargé du gameplay ce handler recevant directement des commandes du genre 'move_right' 'move_left' (définis dans un enum par exemple ou en chaine de caractere) Voili voilou si certains on des idées bien précises sur d'autres sujets ou souhaitent réagir par rapport à ce schéma, ce forum est fait pour ca. En tout cas il y a une chose que je souhaiterais comme une règle absolue pour ce projet. C'est que Aucune classe ou fichier ne sois codé sans avoir été conçu ensemble au niveau du prototype objet. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 07 Août 2011 à 20:31
Messages : 4017 GCPoints : 347288	Je suis tout à fait d'accord avec ta règle absolue. Pour ce qui est du ConfigurationManager, j'ai écrit un système de propriétés accessible dans l'ensemble du programme, et qui sont définies à la compilation - pas de risque d'accéder à une propriété qui n'existe pas, etc... Avec un peu de sucre syntaxique, ça ressemble à: Code : C++ // Déclaration d'une propriété (hors du corps d'une fonction ou d'une classe): DECLARE_GLOBAL_PROPERTY(Path,To,My,Property) // Accéder à une propriété (dans une fonction): GLOBAL_PROPERTY(Path,To,My,Property) // Changer une propriété (dans une fonction aussi): SET_GLOBAL_PROPERTY((Path,To,My,Property),value) // Enfin, pour définir une propriété (dans un fichier cpp): REGISTER_GLOBAL_PROPERTY((Path,To,My,Property),default_value,help_text) Pour l'instant, ce système utilise des variants (QVariant) mais peut être adapté avec des templates je pense. L'avantage, c'est que les accessions/changement de propriété se font en O(1), et ce quelque soit le nombre de propriétés. Pour revenir à la structure, je suis d'accord avec la machine à états, par contre, je ne comprend pas le 'GameCorpPlatformGame', ni le GameSystem (enfin, pourquoi une classe abstraite, vu qu'il n'y aura qu'une classe de type 'Engine...') Après, il reste aussi l'architecture de la mise à jour du jeu. Je vais y réfléchir. Pour le reste, je pense qu'on aura pas l'architecture finie avant de savoir les bibliothèques que l'on utilisera... Sinon, quel logiciel utilises-tu pour le diagramme ? Dernière édition le 07 Août 2011 à 20:41
Voir le profil Envoyer un message privé SEB	Posté le 07 Août 2011 à 20:43
Messages : 554 GCPoints : 103313	Alors je dois dire que j'ai pas vraiment tout compris à ton property manager. XD j'ai plus ou moins compris que ca permet d’accéder à une clef a n'importe quel endroit du code avec une simple macro. Mais je ne sais pas si on peut rapprocher ca de ce à quoi je pensais avec mon 'ConfigurationManager' pour moi le configuration manager était plutôt un système simple de lecture et plus rarement écriture dans un fichier de config de quelques valeurs spécifiques à l'utilisateur. Si c'est aussi de ca que tu parlais je voudrais bien voir plus en détail ton système car je pense avoir raté des éléments. Le GameCorpPlatformGame est simplement la pour avoir une architecture le plus générique possible concrètement toute la partie EngineCore, GameSystem, StateMachine, ConfigurationManager et ControlsManager pourrait être réutilisé pour créer un autre jeu. Et pour cela il suffirait de créer une nouvelle sousclasse de GameSystem. En fait GameSystem peut etre associé à la partie 'script' dans les moteur qui fonctionne avec scripts. Pour le diagramme j'utilise le logiciel yEd qui est gratuit et tres simple pour faire de petit croquis rapide comme celui la. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 07 Août 2011 à 20:56
Messages : 4017 GCPoints : 347288	En fait, avec mon système de propriétés, il n'y aurait plus vraiment de 'ConfigManager', juste une classe chargée de sérialiser/désérialiser les propriétés. Les propriétés, d'une certaine manière, 'se gèrent toutes seules' ;). Je vais détailler ça dès que possible (peut être le mettre aussi en code snippet dans le forum). Merci pour le lien, je teste yEd de suite. Dernière édition le 07 Août 2011 à 20:56
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 15:16
Messages : 554 GCPoints : 103313	Dans le cadre d'une 'sauvegarde de partie' ou de score etc.... je vois bien l'intéret d'un tel système. Mais pour simplement quelques configs liés à l'application je pense qu'un petit config manager est suffisant. Et ca peut être un bon exercice pour les 'moins avancés' en c++. Pour le système de mise a jour du jeu, il y a deux optiques je pense : un executable annexe 'type launcher' comme dans Hollyspirit ou alors simplement une requête faite au démarrage par l'appli. sachant que si internet est coupé il faut quand même pouvoir jouer. Je n'ai pas vraiment de préférence, si je devais prendre une décision moi même j'utiliserais une requête au lancement de l'appli (un etat check version avant l'intro) mais si la majorité préfère un launcher je n'ai aucun problème avec ca. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 08 Août 2011 à 21:57
Messages : 4017 GCPoints : 347288	Pour la mise à jour perso je préfère un launcher. Pour l'architecture, voilà ce que j'ai fait (pour l'instant...). Je suis ouvert aux question/remarques ;) La mise à jour des entités est optimisée par l'utilisation d'un pseudo-octree (simplifié ici vu que le niveau est quasi-linéaire). Je pense que certains noms sont à rechoisir (c'est surtout pour l'architecture en tant que telle). Pour les flèches: - trait pointillé + flèche noire = utilisation - trait pointillé + flèche blanche = implémentation - trait continu + flèche blanche = héritage de classe - pour le dernier type... je me souviens plus ^^
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 22:24
Messages : 554 GCPoints : 103313	C'est quoi la différence que tu fais entre implémentation et héritage? Parceque c'est quasi pareill quand même. En fait je pense comprendre que les 'implémentation' sont forcément finale. Cependant je n'aime pas le voir comme ca car pour moi on doit toujours etre prèt à sous classer donc en théorie une classe finale n'a pas une grande différence avec une autre. Si ce que tu veux dire c'est qu'il n'y a aucun code dans les classes parentes alors tu met 'interface' comme prototype ou si il y a quelques fonction framework tu met 'abstract'. Apres au niveau du 'use' moi en général je l'appelle plutôt 'contient un' et l'autre qui est la composition (avec le losange) dis que le moteur est composé d'entité. Bref ce sont des considérations peu importante ici. J'ai également réfléchi à cette partie du système et il y a des choses que j'ai pensé de la même manière d'autres que j'avais oubliées donc je vais donner mon avis. Déjà pour moi ce n'est pas le moteur qui contient les entités c'est le level, le moteur contient des composant d'entité (comme des sons ou des graphismes) mais il ne contient pas les entité en soi. Ensuite effectivement les entité doivent connaitre leur 'level' et le level a mon avis doit connaitre toutes les entités pas uniquement les animated object. Il peut les stoquer dans des collections différentes par type mais il doit tout connaitre. Ensuite le découpage en scriptobject, character et item est discutable mais se défend. Donc pourquoi pas. Mais par contre ce qui ne me plait pas dutout mais pas dutout dans ce schéma c'est la distinction entre le DistantPlayableCharacter et le LocalPlayableCharacter. Si cela veut bien dire ce que je pense (à savoir un joueur sur le réseau et un joueur local) dans ce cas je ne suis franchement pas d'accord pour moi le caractère 'personnage' doit avoir une seule classe et il faut un simplement une classe de contrôleur avec deux spécialisation une pour le local et une pour le distant qui répercute les actions sur l'unique classe de character jouable. Je vais essayer de poster le diagramme de ce que j'imaginais. Pour que les nuances soient claires. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 09 Août 2011 à 08:49
Messages : 554 GCPoints : 103313	Voila en gros ma version de cette partie : Donc le level est contenu dans l'état 'levelstate' de la machine générale qui contrôle la flowchart. Ce level connait toutes les entités sans exception (qui pourront être triées un peu plus par type c'est à voir..). Parmi ces level entity je distingue deux grandes sous catégorie : 1 les élement statiques dans le sens "ne bougent pas et n'ont aucune autre conséquence que d’être la. (un élément statique peut avoir une représentation 3D animée en terme de modèle mais pas en terme de TRS. 2 les éléments qui ont un comportement (behaviour) dans le sens ou leur existence représente plus qu'un simple fait d'être présent. - Ces element a influence sont séparé en trois grandes catégories : 2.1 Les entité dons le comportement est défini par des règles bien stricte en général matématique. Par exemple des 'point list folower' je pense par exemple ici à des plateforme se déplacant de point en point, ou un élément qui aparait puis redisparait avec un interval de temps de quelques secondes par exemple. 2.2 Les items qui sont des elements que l'on ramasse dans le niveau ou que l'on acquiert et qui s'applique sur les acteurs (par exemple en leur augmentant leur score ou en réduisant certaines caractéristiques du personnage etc...) 2.3 Les actor entity qui sont tous les objet que l'on pourrait considérer comme 'vivant' avec une volonté propre. Il ont tous une liste d'actions possible a faire par eux, mais sont distingué en 'player' et PNJ dans le sens ou pour les Player ce sera le contrôleur qui décidera de quel action effectuer à un moment donné alors que pour les PNJ ce sera la machine à état qui sera chargé de faire ce choix. Voila globalement. Je me rend compte d'une chose que l'on a oublié tous les deux tout en écrivant cela et c'est la notion de 'parentée/contenu'. Concrètement il faut que nous puissions avoir une pièce qui est sur une plateforme mouvante et qui la suive, je pense qu'il faudrait donc rajouter une agrégation quelque part peut-etre directement de BehaviourEntity vers BehaviourEntity (vivi je ne me suis pas trompé ^^) NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 09 Août 2011 à 12:12
Messages : 116 GCPoints : 23144	Selon tes schémas, peux-tu préciser le comportement de: - Je veux tous les objets avec les lesquels entrer en collision va m'immobiliser. - Je veux tous les objets avec les lesquels entrer en collision va déclencher un évènement. - Je veux lancer l'action FastRun (ou une capacité quelconque) si mon personnage l'a récupéré. - Je veux charger un niveau. - Je veux attribuer un filtre de couleur à tous les objets.
Voir le profil Envoyer un message privé SEB	Posté le 09 Août 2011 à 12:37
Messages : 554 GCPoints : 103313	Ce que tu demande c'est des algos grosso modo c'est ca? ou pluto des UML de diagramme de séquence? Je vais essayer de répondre a tes questions textuellement mais si tu le souhaite je pourrais faire ces 'algos' ou diagramme. Question 1 : - Je veux tous les objets avec les lesquels entrer en collision va m'immobiliser. Je dirais déja? pourquoi tu veux ca? ... je vais répondre à la question mais je vais d'abord faire une projection j'imagine que tu as besoin de saoivr cela pour déterminer si tu est immobilisé ou non. Je dirais que dans ce cas la classe 'PlayerEntity' au moment de la construction de sa représentation 3D devra spécifier au moteur (graphique ou physique) qu'il souhaite recevoir un callback lors d'une collision. Dans ce callbakc je ferais en sorte d'avoir acces au player et à l'entité collisionnée que je pourrais caster en LevelEntity et via son type qui pourrait etre stoqué comme attribut de base dans la classe mere je pourrais savoir si cela doit me bloquer ou non. Deuxièmement il existe dans beaucoup ed système de physique une notion de layer qui pourrait peut-etre même nous épargner tout cela. Dans le cas ou nous voudrions quand même avoir réellement l'ensemble des objet qui pourraient m'immobiliser, j'ai deux solution soit je parcours le tableau de toute les entite du niveau et je verifie leur type. Soit j'ai déja stoqué un tableau dans le level quir egroupe toutes les entites 'bloquantes'. Question 2 : Je veux tous les objets avec les lesquels entrer en collision va déclencher un évènement. Exactement la même réponse que la précédente (il faut dire qu'il n'y a que le type qui change. Question 3 : Je veux lancer l'action FastRun (ou une capacité quelconque) si mon personnage l'a récupéré. Si je veux lancer le fast run cela viendra très probablement d'une commande clavier ou réseau donc c'est une information qui sera redirigé dans un premier temps par les ControlsManager (du premier schéma) Vers l'InputActionHandler qui sera très amis avec le LevelState qui analysera la touche et passera par le PlayerControler pour dire en quelque sorte 'utilise ton objet 1' par exemple. Le PlayerControler connaissant le player va lui transmettre ce message et le PlayerEntity va donc chercher dans son 'sac de contenu' qui est représenté par l'agrégation, l'item numéro 1 (qui sera de type Item donc) il apellera la fonction abstraite applyOn( this ) qui elle lui augmentera son attribut 'vitesse' et renverra true parceque c'est une compétence 'active' c'est à dire qu'elle a autre chose à faire (se désactiver). Le player stoquera donc cet item comme item actif et a chaque update il lui demandera si il est encore actif... au bout de N secondes, l'item dira qu'il n'est plus actif et le Player apellera donc removeFrom( this ) puis le retirera des items courant. Question 4 : Je veux charger un niveau. Heuu je vais pas détailler tout le chargement pour le moment si? Je peux simplement dire que le state selection de level aura transmi un parametre 'nom de niveau' ou 'identifiant' au LevelState qui se chargera dans le init de loader le ficheir de niveau.. Question 5 : Je veux attribuer un filtre de couleur à tous les objets. Je vois encore mal pourquoi faire mais il te suffi via le level de parcourir tous les items et de leur dire de changer la couleur ambiante des materiaux leur 'iSceneNode'... NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 09 Août 2011 à 12:58
Messages : 116 GCPoints : 23144	Oui je voulais juste avoir un peu le processus tu vas passer pour exécuter les fonctionnalités. Pas la peine de s'embêter avec du diagramme de séquence, c'est juste de l'explication par rapport aux classes que tu as proposées. Ce qui m'inquiète dans un premier temps, c'est comment tu penses gérer la physique: mon perso essaie de bouger sur la droite => est-ce qu'il avance vers la droite? est-ce qu'il va reculer(un tapis roulant par exemple) est-ce qu'il sera bloqué? est-ce qu'il va tomber? est-ce que ça va déclencher un évènement? Et qui va gérer la physique? Pour la question 4, l'un des problèmes est: qu'est-ce que je vais vider tout le contenu du LevelState actuel? que se passe-t'il s'il y a un "relancer le même niveau remis à 0?" Quel objet possède le LevelState? Enfin l'idée de changer la couleur reviens un peu à comment et qui stocke les attributs graphiques de chaque objet? (question similaire au problème du moteur physique)
Voir le profil Envoyer un message privé SEB	Posté le 09 Août 2011 à 13:46
Messages : 554 GCPoints : 103313	Pour la physique je pense que cela dépend franchement des choix que l'on fera dans le sujet sur les 'Level' Il y a plusieurs alternatives qui se présente. Mais globalement soit on utilise complètement un moteur physique et on utilise des forces pour tout faire. Soit on utilise des solutions plus 'alternatives' en limittant le rôle du moteur à de la detection de contacts. Mon idée préliminaire je dirais que déja c'est le personnage qui avance (cela fait beaucoup moins de mouvement dans la gestion du graphe de scène et je pense que si on part du principe que le décor est statique, ce sera beaucoup plus efficace pour le moteur physique (encore une fois, si nécessaire je ne suis pas encore certain de la nécessité d'un moteur physique) mais quoi qu'il en soit même pour le moteur graphique limiter les mouvement dans le graphe de scène ne peut etre qu'un bennefice. Donc je suis pour le mouvement du player et de la caméra et non pas du level entier par rapport au personnage. Ensuite on pourrait immaginer utiliser une boite englobante invisible (ou sphere ou autre) qui soit chargé de recevoir les callback de collision (fournis par Irrlicht ou le moteur de physique) Ce qui fait que lors d'un déplacement le callback sera automatiquement appelé par le moteur en question il suffira donc de tester ce qu'il y a autour (fourni par le callback) pour appliquer les différents effets (tapis roulant, mur, evennement). Si par contre comme je suis en train de le dire la, nous cherchons à répondre nous même à de simple détection de collision alors il faudra également envoyer un rayon vers le bas pour détecter si le sol s'est dérobé et enclencher une chute. Pour la question de 'recommencer le niveau' effectivement il y a la possibilité dans un premier temps de tout recharger. Mais il est aussi possible (dans le fichier de level) de distinguer les éléments 'evennementiels' qui doivent être réinitialisé contrairement aux autres. Ceci permettant de réduire considérablement le rechargement. L'objet qui possède le level state est le StructuredFiniteStateMachine représentant la flow chart de base. Pour les attributs graphiques de chaque objet il sont initialement stoqués dans des fichiers. Mais une fois chargé ils sont confiés directement au moteur graphique et ne sont a priori pas utilisés par les entité sauf pour modifications mineures auquel cas l'entité s'adresse a sa représentation graphique stoquée dans irrlicht. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé SEB	Posté le 09 Août 2011 à 17:41
Messages : 554 GCPoints : 103313	Voila ici un lien vers le fichier direct de l'image du diagramme qui évolue. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 09 Août 2011 à 22:41
Messages : 4017 GCPoints : 347288	héritage: pas forcément complet... Le moteur ne contient pas les entités mais les mets à jour (d'où le texte 'Updates'). D'ailleurs, sur ton schéma, je ne vois pas à quoi sert le LevelState si EngineRunState est l'état en cours pendant le jeu. En gros, le moteur possède le 'Level', et met à jour le 'Level', donc pas de LevelUpdate. Pour le reste, je pense que pour plus de flexibilité pour le designer (et plus de facilité pour nous), il faudrait rajouter: [LevelEntity] --> [LogicEntity] --> [ce que j'avais mis dans ScriptObject] Ainsi, les entités logiques seront représentées par une zone invisible (mais présente dans la gestion des collisions). Lorsque le joueur rentrera dans une de ces zones, le système de collision va simplement appeler la méthode 'run' de l'entité (qui va, par exemple, changer de couleur des objets, gagner le niveau, etc...) Cela n’empêchera pas d'avoir un gestionnaire de script 'globaux', ie qui vont être exécutés tout le temps (pas juste par callback). Pour le log, peux-tu expliciter les LogHandler et GraphicLogHandler ? Enfin, une dernière question: utilité de 'StreamedNode' ? Irrlicht n'est pas multithreadé du tout, j'ai bien peur que tout chargement ne se fasse de manière séquentielle... Dernière édition le 09 Août 2011 à 22:50
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 00:09
Messages : 554 GCPoints : 103313	Citation : Le moteur ne contient pas les entités mais les mets à jour (d'où le texte 'Updates'). D'ailleurs, sur ton schéma, je ne vois pas à quoi sert le LevelState si EngineRunState est l'état en cours pendant le jeu. En gros, le moteur possède le 'Level', et met à jour le 'Level', donc pas de LevelUpdate. Ok je vois ou est le mal entendu ^^ ! En fait je confirme pour moi ce n'est pas le moteur qui met a jour les entité. Le moteur met a jour les représentation graphique et sonnore des entites mais pas les entites en soi. Il faut voir que les spécialisation de state qui sont le plus à gauche (celle qui commence par engine) ne font PAS parti de la même machine à état que ceux de droite. Les état de droite compose une sous-machine a état qui évolue dans le EngineRunState mais effectivement il manque quelques fleches et notes pour que ca soit vraiment clair. Les logic entity effectivement sont a rajouter (je ferais ca demain) Par rapport au log l'idée est d'avoir une classe de log possédant des fonctions statiques message, warning et error cette classe contiendra une instance statique de LogHandler qui pourra être 'chainé' avec d'autres log handler typiquement cela permettra d'avoir soit des logs uniquement dans un fichier texte, soit uniquement affichés dans une console de dev dans le jeu soit les deux en meme temps. edit: désolé j'ai oublié de répondre pour le streamed node. donc j'édite ce message. Je sais très bien que irrlicht n'est pas streamé, mais il offre la possibilité de surcharger sa classe de node et donc c'est bien à des choses de ce genre que cela sert. Nous fournirons initialement l'ensemble de tous les nodes irrlicht mais certains seront de ces fameux 'streamed nodes' ce qui fera que irrlicht sera tranquil car il pourra travailler avec l'ensemble des noeuds (bounding box etc...) mais pour ce qui est du chargement concret du matériel graphique nous serons relativement libre de faire ce que nous voulons. Concrètement les seules choses que nous serons obligé de faire de facon séquentielle seront 1 dans le cas ou le node devient 'visible' dans ce cas si nous n'avons pas eu le temps de charger il faudra forcer le chargement. 2 dans le cas ou nous ne sommes pas dans l'urgence de rendu, il suffira de compter le temps pris par l'update, d'en déduire un nombre de milliseconde restant et d'utiliser ce temps pour monter en mémoire vidéo quelques éléments. Donc les deux seuls point sur lesquels nous sommes a peu pres obligé d'etre syncronisé avec le moteur de rendu ce sont : 1 L'affectation dans le graphe de scène. 2 Le transfert des data en mémoire vidéo. Ceci dit si les niveau sont relativement répétitif irrlicht gérant déja un système de cache de mesh, les monté/descente en mémoire vidéo devraient quand meme être relativement limitées. Dernière édition le 10 Août 2011 à 08:37 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 10 Août 2011 à 19:22
Messages : 4017 GCPoints : 347288	Ok pour les états, je n'avais pas vu, c'est tout à fait logique maintenant. Pour ce qui est du log, en gros le logger centralise tous les appels de log, puis les redistribue aux logHandlers concernés, si je comprend bien. Pour le streaming, l'entends-tu par multithreads ou par chargement avec le thread principal mais pendant la mise à jour ? Le multithreading aura toutes les chances de foirer, ne serait-ce que pour les textures, vu que de toute façon va falloir appeler des méthodes du videoDriver qui elles ne sont pas du tout thread-safe. Par contre, dans l'autre cas, ça pourrait être faisable, en chargeant par petits bouts. Dans les deux cas, faudra réécrire des chargeurs de ressource pour Irrlicht... et je pense à stylobique qui aimerait avoir du collada... Donc à mon avis, le jeu n'en vaut pas la chandelle.
Voir le profil Envoyer un message privé SEB	Posté le 10 Août 2011 à 20:12
Messages : 554 GCPoints : 103313	Oui en gros c'est cela pour le log handler. Sauf qu'il ne fait pas de trie, il dispatch tout à tout le monde. Pour le streaming, l'entends-tu par multithreads ou par chargement avec le thread principal mais pendant la mise à jour ? J'ai envi de dire : les deux. (j'avoue je viens de regarder un peu plus en détail irrlicht pour etre sur de ne pas dire de bétises en tout cas pas trop parcequ'il y avait des choses a vérifier avant de pouvoir faire cela) Donc concrètement je parle d'un streaming threadé pour la partie 'montée en mémoire des fichiers' et 'lecture des data transformation en data de base' et pour cela irrlicht heureusement pour nous ne fait aucun appel au vidéodriver. La création des buffer vidéo est 'déja' streamé dans le thread principal. Donc conrètement ce sera quasiment super simple à faire. Effectivement sur certain loader comme le collada il faudra utiliser une petite astuce je pense car ils chargent des 'scènes' complètes su lieu d'un seul et unique node. Donc On pourrait contourner le truc en créant un scene manager temporaire basé sur un video driver null dans lequel on chargerai le colada dans un thread et au moment ou le rendu 'concret' demande au 'Streamed node de faire le rendu' on parcour l'ensemble des nodes root du scene manager de collada et on transmet simplement l'appel à render. Donc pour faire simple un chargement streamé threadé pour la partie montée des fichier en mémoire (au minimum) au mieux pour du chargement en ram des buffer de mesh. Et ensuite chargement streamé dans le thread principal pour le passage en mémoire vidéo. Donc il y a aucune modifications a faire sur irrlicht, uniquement bien utiliser le ISceneNode et les threads. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 11 Août 2011 à 20:34
Messages : 4017 GCPoints : 347288	Mouais, je suis moyennement convaincu... De toute façon, je propose de ne pas forcément inclure le streaming dans le prototype (pour avoir le prototype plus rapidement). Cela permettra aussi de profiler un peu pour voir si c'est vraiment nécessaire (perso ça m'étonnerais beaucoup que le jeu dépasse les 600-700 Mo sur le disque, ce qui est de nos jours facilement chargeable entièrement en RAM).
Voir le profil Envoyer un message privé SEB	Posté le 11 Août 2011 à 20:46
Messages : 554 GCPoints : 103313	Inclure le streaming ou pas consistera simplement à instancier des StreamedNode ou pas donc effectivement de ce point de vue la modification sera à priori relativement simple si toutefoins on venait à ne pas l'intégrer dans ce que tu appelle le 'proto'. 600 ou 700 Mo Facilement chargeable entièrement en ram la n'est pas la question, c'est plutot une question de temps. Mais effectivement pouvoir faire la comparaison sera intéressant. NextGine : 3D games engine Nombre de lignes actuel : 77683

GameCorp - Index des forums

Projets

Projet communautaire

[Projet la relance] 15 Uml, objet quand tu nous tiens !

Répondre

Espace Membre

Partenaires

[Projet la relance] 15 Uml, objet quand tu nous tiens !