rewind a écrit 3416 commentaires

J'ai une question. G'MIC permet de traiter des images et d'avoir des pipelines assez complexes. Est-il prévu un jour d'intégrer des fonctions de générations, notamment pour générer des textures, éventuellement avec du bruit cohérent ? Les exemples données sur libnoise sont tous codés mais je me dis que ça pourrait être intégré.

Est-ce que tu peux expliquer en quoi 2 ans fait vieux pour un moteur physique ? (Il manque des petits détails ou des grosses fonctionnalités toujours pas en place ? Des bugs pas corrigés ?)

Le «problème», c'est qu'il y a eu des changements depuis cette dernière version, mais aucune release. J'avais vu une roadmap (mais je ne la retrouve plus) et il y avait encore des fonctionnalités prévues. Donc, le logiciel n'est pas abandonné, mais il n'y a plus de release depuis un moment.

Je pense qu'utiliser un moteur physique sans comprendre un minimum la mécanique du solide, c'est dangereux. J'ai toujours eu horreur de la physique, mais j'ai quelques restes qui me permettent de comprendre grosso-modo les termes et leurs implications. Si je change un paramètre, je sais quel effet ça aura. Et ça, ça aide beaucoup. Du coup, le tâtonnement, il est très dirigé, ce n'est pas non plus du free style complet. Le manuel, d'ailleurs, est très bien fait de ce point de vue, il est fait par un physicien qui explique à des informaticiens ce qui se passe. Mais je pense que du coup, il ne va pas assez loin au niveau des explications du pourquoi du comment.

ça me fait juste peur : c'est quoi ce 0.001, ça sort d'où ? et le 0.98 etc…

Ça sort de mon chapeau :P Non, sérieusement, comme dit plus haut, et si tu suis les liens dans la dépêche, ces valeurs ont une définition physique réelle. Le 0.98, ça veut dire que la balle va perdre un peu de son énergie et donc va rebondir un tout petit peu moins haut. Et le 0.001, j'y suis allé par tâtonnement, n'ayant aucune idée des valeurs réelles pour ce genre de matériau. Au début, j'avais mis quelque chose de plus haut et j'obtenais un comportement digne des vrais balles rebondissantes (ça «accrochait»). J'ai donc descendu la valeur jusqu'à ce que ça me semble plus glissant.

En fait, une fois qu'on comprend la signification physique, on peut jouer un peu. Le manuel donne aussi une indication essentielle pour savoir comment est calculé la friction et la restitution quand deux solides entrent en contact : pour la friction, c'est une moyenne géométrique des deux frictions ; pour la restitution, c'est le max des deux restitutions. Ça aide à comprendre un peu comment ça va se comporter.

Les plus légers que l'air n'ont pas une gravité plus faible mais une densité plus faible ;)

Justement je trouve pas génial le fait de "jouer" avec les forces, genre "appliquer une force contraire à la gravité en permanence".
C'est compliqué si le déplacement se résume à l'application de force, alors c'est vrai que c'est pratique, que ça fait un joli déplacement réaliste.
Par contre, si je compte faire une chauve-souris dont le déplacement (que j'ai) prévu est une sinusoïdale, si je dois jouer sur la "force contraire à la gravité" (mais pas en permanence pour le coup…)

Oui et non. En fait, je n'y avais pas pensé tout à l'heure mais Box2D permet d'appliquer un facteur (éventuellement nul) à la gravité sur chaque corps indépendamment. Donc, c'est bien prévu par la bibliothèque d'avoir ce genre de situation bizarre.

Ok, j'achète ;)

Mais puisque tu as réponse à tout :P dans ton système, tu es obligé de gérer tous les événements au même endroit non ?

Premièrement, je me demande comment gérer des objets dont la gravité ne serait pas le seul propos. Par exemple, pour un mario bros (oldschool) autant le sol serait un solidet, mais les tiles/plateformes sur lesquels on saute ? si on en fait des solide ils vont tomber ?

Non, ils ne vont pas tomber, si tu en fais des objets statiques, ils restent là où ils sont, ils ne sont pas soumis à la gravité.

Peut-on ajouter des interactions autre que le contact ? par exemple une porte, qui nécessite une clef, à la collision, peut-on sortir (callback) du moteur pour savoir si on ne passe pas la porte ou bien si ca passe (on ouvre la porte), idem pour les bonus peut-on faire en sorte que la collision avec celui-ci fasse une action (le prendre).

Le moteur physique n'est qu'un élément du jeu. Donc, il y a une partie de la logique du jeu qui sera en dehors. Pour ton exemple avec la porte et la clef, je vois deux solutions : premièrement, tu peux créer la zone qui capte uniquement quand tu as récupéré la clef, ce qui fait qu'avant, tu ne peux pas passer ; deuxièmement, avec Box2D, tu peux créer un listener quand un objet entre en contact avec un autre, il suffit alors, dans ton listener de tester si tu as la clef. Pour ton bonus, c'est pareil, un petit listener et hop.

et si je veux faire un ennemie qui marche aux murs/ aux plafonds (une araignée)

Là, je dois dire que tu me pose une colle. Je pense que c'est possible, il suffit d'appliquer une force contraire à la gravité en permanence mais je n'ai jamais essayé ni vu de choses à ce sujet.

Deuxième remarque (qui est un peu le corolaire de la première, vu la complexité à sortir du modèle) j’ai un peu peur que de nombreux jeux basé sur un tel moteur 2d, ne soit rien de plus qu’un jeu de physique.

Ou pas. Dans tous les jeux, tu dois gérer des collisions avec les éléments du décor. Tu peux le faire à la main pour des cas simples, mais dès que le jeu devient un poil complexe, tu te retrouves à réinventer la roue. Et là, tu découvres qu'un moteur physique, ça fait déjà tout et sans doute mieux. Et ça ne veut pas dire que ton jeu est basé sur la physique, juste que tu délègues cette partie à une bibliothèque qui le fait mieux que toi. Box2D a l'air suffisamment flexible pour traiter un grand nombre de situations (en tout cas, je ne me sens pas limité pour l'instant) donc, ce n'est pas vraiment un frein. Si jamais ça arrive, j'en ferai part dans un prochain article.

Ma question portait sur ce cas là en particulier, pas sur le cas général (auquel cas, je suis d'accord avec ce que tu as dit).

En programmation, plus les classes sont petites et cohésives et plus c'est facile a maintenir.

Oui mais bon, il y a des limites. Par exemple, si je crée un composant CoordX et un composant CoordY, ça n'a pas de sens parce que les deux sont toujours associés donc on a tout intérêt à mettre tout ensemble.

Pour des messages simples, ça marche. Mais après, je trouve que ce n'est pas très flexible. Si ton type Message est simple (c'est-à-dire sans héritage et polymorphisme), tu ne peux pas faire grand chose.

Oui, la formalisation est intéressante mais incomplète encore, je pense. Et comme tu dis, ça ne fait pas tout. Par exemple, on ressent assez vite le besoin d'avoir en parallèle un outil de message ou d'événements pour communiquer entre entité. Et ça s'explique assez bien. Avec les systèmes, on a plutôt un truc de type polling, on examine et on modifie l'état de manière régulière. Il faut donc contrebalancer avec un truc de type événement, c'est-à-dire où le polling est sous-optimal. C'est en tout cas ma façon de le voir. Mais ce qui est drôle, c'est que dans pas mal de présentation, soit c'est présenté en même temps, en disant que ça fait pas partie d'un système à entité, soit c'est relégué presque aux oubliettes en disant que souvent, on le met, mais sans voir qu'en fait, c'est indispensable.

bougez pas, je ---> [ ]

Reste dehors, hein, ça ira à tout le monde ;)

En fait, dans un précédent projet, je faisais de l'entity system avant que ça s'appelle comme ça! Il faudrait un historien pour savoir à partir de quand et par qui ça a été théorisé.

D'après tout ce que j'ai pu lire, effectivement, ça existe depuis longtemps même si ça ne s'appelait pas comme ça et qu'il y avait beaucoup de variantes. Après, j'ai l'impression que les articles que j'avais mentionné (notamment celui sur les MMO) ont été un début de théorisation (notamment le parallèle avec les bases de données). D'ailleurs, c'est le même auteur qui a fait le wiki sur la question. Mais je pense que le concept n'a pas été complètement exploré ni assez théorisé (les variantes notamment).

Ce qui me motiverai plus, ça serait un projet plus petit, genre un moteur de defense tower assez customizable pour que les gens puissent faire leur propre lvl et modifiant la difficulté, voir certaines règles de base.

Ok, une fois que j'ai fini mon jeu (prévois 2 ans, au bas mot, ça te laisse de la marge), on se fait ça.

Mais l'autre soucis est que je suis très stricte et exigeant sur la qualité du code, du coup ça serait trop chiant de bosser avec moi et je me ferais jeter de la team illico :D

J'aime beaucoup le beau code et je suis très chiant aussi. Si on a la même chiantitude, ça devrait aller. T'auras qu'à jeter un coup d’œil à mon code pour me dire s'il est sale ou pas selon tes critères.

Pourquoi ne pas juste les ranger les composants dans des listes et les faire réferencer par les entités ?

Normalement, c'est ce qu'il faut faire, les composants sont rangés par type (ça s'appelle le modèle ES Alpha et ça se rapproche d'une base de données). Dans Artemis, ils ne font pas comme ça, c'est l'autre méthode, les composants sont dans les entités, j'aime moins.

Comme ça, pour processer un type de composant, tu attaques directement la liste sans te soucier de quelle entité est connectée dessus (ça rejoins un peu l'idée du scene graph en fait), et tu n'as pas besoin de faire une lourde requete sur des associations entre entités et composants !

Oui et non. Souvent, une entité à plusieurs composants, et un système a besoin de plusieurs composants de cette entité (typiquement, il va lire certains composants et il va en écrire d'autres), donc ça sert à quelque chose de savoir à quelle entité appartient tel composant. Pour certains composants, on peut faire comme tu dis mais ça ne change pas grand chose par rapport au cas de base finalement.

J'utilise un entity system

Et alors ? Est-ce que ça te plaît comme manière de penser ? Je vois que tu as déjà pas mal de code, ça m'impressionne. Et que tes composants sont tout petits, tu n'as pas peur d'avoir trop découpé ? Il y a des choses, je me demandais comment j'allais faire, je pourrai m'inspirer de tes techniques ;)

C'est ce que j'ai cru comprendre et je me suis à un moment posé la question :)

Tu peux prendre ton temps pour la réponse, je ne vais pas trop vite ;)

Et je me suis trouvé une autre excellente excuse pour eviter d'entrer dans un projet qui me prendra beaucoup de temps.

Oui et non. Je n'ai pas beaucoup de temps non plus, donc j'essaie d'avancer lentement mais sûrement. J'ai une liste de choses à faire qui s'allonge donc, ça devrait aller pour m'occuper un moment. Si quelqu'un me rejoint à un moment, ça devrait aller avec tous les articles et toute la documentation que j'écris au fur et à mesure.

Il est développeur de jeu, c'est forcément quelqu'un de bien ! :P

Le code est disponible sous les termes de la version 3 de la GPL et les ressources sous les termes du contrat Creative Commons dans sa variante paternité, partage à l'identique, en version 3.

Pourquoi ne pas avoir tout mis sous GPLv3, code et données ?

Nous l'avons utilisé principalement pour des jeux de plates-formes mais nous pensons qu'il peut très bien être utilisé pour d'autres types de jeux, par exemple pour des jeux vue de haut.

Ce qui manque pour ce moteur de jeu, c'est de la documentation. Parce que, oui, c'est peut-être possible de faire d'autres types de jeu, mais si on veut se faire une idée plus précise, on peut difficilement. Sans compter qu'il y a des choix qu'on pourrait questionner comme le fait de ne pas avoir choisi Box2D pour le moteur physique (y a-t-il une raison particulière ou c'est juste un petit NIH ?)

Après sur le papier, ça a l'air intéressant, ça offre tout un tas de fonctionnalités sympathiques. Et ça donnerait presque envie de plonger dedans et de contribuer. Je pense que quand j'aurai fini mon jeu, je jetterai un coup d'œil, j'aurai un peu plus de bouteille sur les problèmes et les solutions et je serai sans doute plus utile que maintenant.

C'est bien ça, une nouvelle version de nanimstudio ! Du coup, ça tombe bien que tu montres cet exemple parce que j'avais une question à propos des animations à une seule frame. Je vois ici que tu mets la durée à une valeur arbitrairement grande, est-ce que c'est la bonne façon de faire ?

Le choix d'une vue en 3d isométrique nous a amené à choisir Tiled pour l'édition des niveaux. Là aussi c'est un choix par défaut, car il n'y a pas beaucoup d'alternatives sur ce "marché".

En fait, plus j'y pense, plus je me dis que Tiled fait soit trop de choses, soit pas assez. Tiled pourrait être un simple logiciel pour construire des cartes et rien d'autres. Le fait est qu'il sait faire d'autres choses comme mettre des formes sur la carte. Mais du coup, ces formes et leur signification dépendent beaucoup du jeu qui va les charger. Et donc, il y a une phase de conversion à faire dans tous les cas. On peut s'en sortir plus ou moins bien avec les propriétés associés aux objets mais ça devient vite lourdingue.

En fait, Tiled devrait être un composant parmi plein d'autres (qui n'existent quasiment pas) pour créer un moteur de ressources de jeu. Mais ça demanderait beaucoup de boulot, notamment normaliser les besoins des jeux de manière à peu près générique. Tout ça, c'est généralement refait dans chaque jeu, et c'est de la perte de temps je trouve. On pourrait aller beaucoup plus loin. L'autre solution, c'est d'utiliser un moteur de jeu complet, avec tous les inconvénients que ça engendre.

Ma bibliothèque laisse le jeu faire le chargement lui même.

Oui, j'ai fait pareil pour libtmx. Même si en C++, on n'a pas un truc plus ou moins standard pour charger les images (à l'inverse de Java), je me dis que les bibliothèques graphiques savent faire ce genre de chose, et le font toutes différemment, donc laissons ce travail facile à l'utilisateur. La seule difficulté, c'est de calculer le bon chemin jusqu'au fichier (puisque les chemins sont déterminés en fonction du fichier courant).

Et maintenant ça marche, mais il me semble que ce genre d'opération n'est pas très très propre.

Dans ce cas, il me semble que c'est pkg-config qui fait mal son boulot. Dans ma manpage de pkg-config, tu as une liste des répertoires qui sont visités à la recherche de .pc.

La suite : avec gcc 4.7, j'ai compilé libtmx (cmake, make…). Résultat (…)

Je pense que la libstdc++ qui est avec gcc ne devait pas être tout à fait complète. Je crois que je vais mettre une dépendance gcc >= 4.8. Le ifdef marche avec gcc 4.6 cependant.

Et pour finir (…)

Celui-là, on me l'a signalé par ailleurs. Je vais regarder ça.

Pour libtmx, on me demande d'installer tinyxml2. Fait via le git du projet, mais n'est pas reconnu.

D'après ce que je vois, pkg-config n'a pas réussi à trouver le .pc de tinyxml2. Je pense que tu as dû utiliser autre chose que CMake pour contruire et installer tinyxml2, parce qu'il y a bien un .pc dans les sources.

Quatre dépendances dont la plupart ne sont pas dans les grandes distributions. Tu vas t'amuser lors de l'empaquetage.

M'en parle pas :D Mais de manière générale, je trouve qu'il y a assez peu de jeu dans les distributions. Dans Debian, par exemple, il n'y a aucun paquet qui dépendait de SFML 1.6 !! Et je ne parle pas de Box2D qui est packagé comme un goret. Donc, je me dis qu'il faudra que je trouve un moyen de fournir un binaire.

Je vais avoir un besoin de cross-compiler pour le jeu que je développe et pour lequel j'aimerais bien fournir une version Windows à moyen terme. Je pensais que j'allais devoir me coltiner le montage d'un environnement de dev sous Windows et que ça allait être très galère. Donc, quand j'ai vu ton projet, j'ai crié hourra et j'ai essayé pour voir si c'était facile. Réponse : oui, c'est facile !

Maintenant, comme je n'en ai pas besoin dans l'immédiat, je peux attendre la correction du bug. Si ça prend du temps cette correction, j'appliquerai ton astuce pour que ça marche. Mais en tout cas, je pense que je vais adopter ta solution de cross-compilation pour Windows. Elle m'a convaincue.

Du coup, j'ai essayé avec le build 20131004 mais j'ai le même bug. Je crois que je vais m'arrêter là pour l'instant et attendre que ce bug soit résolu.