rewind a écrit 3425 commentaires

Pour en avoir discuté un peu avec devnewton, je crois que c'est un constat assez partagé. J'ai déjà discuté aussi avec des gens qui avaient travaillé dans ce milieu et les retours ne sont pas très positifs.

Venons-en aux faits s'il vous plaît: Si demain je veux voir un (vieil) unix propriétaire toujours en service, je vais où ? À la sncf ? À la poste ? À la caisse de carrefour ?

Tu vas chez Renault, dans un magasin de pièces détachées, à l'époque où j'y ai travaillé, tout était géré avec un gros serveur à Paris sous HP-UX, et là où j'étais, on avait des terminaux, soit logiciel (pour les gestionnaires du magasin), soit de vrais terminaux dans le magasin lui-même. C'était fun, tu pouvais taper sur le clavier et c'était tellement lent que le texte s'affichait au fur et à mesure. Et ça marchait aussi pour les commandes à envoyer via des touches. Du coup, tous ceux qui étaient habitué faisait tout à l'aveugle et attendait que ce soit fini pour faire une autre chose.

Bon, ça fait un moment, donc je ne sais pas si c'est toujours en place mais ça ne m'étonnerait pas que ça soit resté à peu près tel quel.

Mais en fait, je m'en fou, je n'ai pas d'avis.

Hahahahahaha ! Non, mais là, arrête, je m'en remets pas… :D

Dans ce cas précis par la concurrence

Je préfère la force de la loi à celle de la main invisible du marché. Typiquement, dans les cas que j'ai cités, dans 90% des cas, tu as un emballage à la con. Et souvent, dans les magasins, tu n'as pas d'alternatives, donc la concurrence, elle ne s'exerce pas. Je préfère orienter les décisions des industriels plutôt qu'attendre quelque chose qui n'arrivera sans doute pas de sitôt.

Ah le retour de la déresponsabilisation des citoyen, le mode de facilité pour dire toujours "c'est la faute des autres".

Déjà tu as tronqué ma citation. Ensuite, dis moi comment un citoyen a le pouvoir de choisir l'emballage que mettra l'industriel autour de son produit. Sérieusement. L'industriel, il fait bien comme ça lui chante, c'est lui qui décide, c'est lui qui a le pouvoir, donc j'estime que c'est lui qui est responsable de ce qu'il met autour de son produit.

D'après toi, les industriels, ils mettent de l'argent dans les emballage, c'est pour se faire plaisir eux-mêms ou juste pare que le consommateur achète quand c'est plus joli?

Franchement, tu trouves que le kilo de plastique autour des clefs USB, ou autour des paires de ciseaux (que les mêmes ciseaux n'arriveraient même pas à couper), il est joli ? On n'a pas la même définition de joli je crois…

Ils l'ont. Ils disent simplement qu'ils préfèrent l'emballage dans toutes les études de consommation.

Ha ben oui, et du coup, l'industriel, il se met un pistolet sur la tempe et dit à ses ouvriers de mettre un gros truc en plastique sinon, il se suicide. Sérieusement, tu confonds tout, je ne dis pas qu'il faut supprimer tous les emballages, mais on peut l'alléger, on peut le réduire, on peut utiliser du recyclable, on peut même le supprimer (c'est ce qui a été fait sur la plupart des yaourts maintenant où le carton autour n'existe plus).

Pour ça il faut une volonté politique, qui sera présente uniquement si il y a une volonté citoyenne. Qui n'existe pas.

Affirmation sans preuve. Je peux t'assurer que si tu donnes le choix entre payer une taxe poubelle et obliger les industriels à réduire leurs emballages, il n'y a pas photos, la deuxième l'emportera haut la main.

C'est fou comme ou peut toujours dire "c'est la faute aux méchants industriels" sans accepter l'idée que les indisutriels ne font que rpondre à la demande de toi et tes voisins…

Personne ne les force à répondre à la demande, demande qu'ils contribuent aussi à fabriquer via la pub. Ils peuvent aussi avoir le sens des responsabilités, et s'ils ne l'ont pas, la loi peut les obliger.

Et vu la note de ton commentaire, c'est fou comme ça marche sur les gens cette façon de les déresponsabiliser, ils adorent cette déresponsabilisation.

Pour l'instant, les industriels ne sont pas responsables de leurs emballages, ce ne sont pas eux qui paient la taxe poubelles. Ha mais tu ne parlais pas de ça ?

Non, c'est une taxe idiote, c'est de l'écologie punitive stupide. Tout simplement parce que les ménages ne sont pas responsables des emballages qui ont été mis autour des produits qu'ils consomment. Et ne viens pas me dire qu'ils ont le choix, non ils ne l'ont pas. Qu'on commence par mettre la pression sur les industriels pour réduire la quantité d'emballage (et la nature aussi, moins de plastique par exemple), et on s'apercevra que la quantité de déchets réduit d'autant.

Faut pas commenter une news si ancienne ! J'ai failli ne pas voir ton commentaire ;)

J'ai quelques remarques, j'ai regardé un peu le tutoriel que tu as mis en ligne pour ta librairie libes, le premier inconvénient que je trouve c'est de tenir une énumération de tout tes composants , le second est de dérivé tout tes composants de cette structure 'struct Component' , ton composant pourrais directement être du type que tu veut avec des templates, si tu tiens à une enumération pourquoi ne pas incrémenté de manière automatique tes composants ? avec les balles , ca va, tu en as quelques un, mais avec une 50° de composants ?

Cette énumération a deux objectifs : premièrement, elle permet d'avoir un id pour retrouver les stores qui vont bien (et là, oui, on pourrait les générer) ; deuxièmement, elle permet d'avoir un id stable dans le temps qui va permettre des sauvegardes faciles. On pourrait faire sans mais on serait obligé à un moment donné de gérer ce problème d'une autre manière moins propre je pense. En plus, dériver tous mes composants de struct Component permet de faire de la vérification de type à la compilation (merci C++11).

La seconde remarque que j'ai , c'est la mémoire vive consommée avec de tel système, de nos jours, j'ai l'impression que les programmeur s'en remettent souvent à la loi de moore, je prends par exemple le jeu que ma femme adore, les sims3, il à clairement été codé avec des moufles, quand je vois ce qu'il consomme par rapport à d'autre jeux au contenu équivalent, je me pose donc la question si un tel système à cause notamment de l'utilisation massive des std::map ne serait pas grand consommateur de ram ?

Pour l'instant, ça va, je n'ai pas encore de problème de sur-consommation mémoire (et si j'en avais, ça m'inquièterait). On est ici face à un compromis à trouver entre avoir une structure qui permet de faire une recherche en O(log n) ou enlever la structure mais faire des recherches en O(n). C'est un compromis temps-mémoire et effectivement, ici, j'ai plutôt choisi de sacrifier un peu de mémoire. Peut-être que je reviendrai sur cette décision plus tard. Pour l'instant, tout va bien.

Non, je ne pense pas. Il n'y a pas moyen de définir des zones qui ont un comportement différent.

Merci pour cette réponse. J'avais vu quelques trucs parmi tout ça au fil des articles mais je pensais pas qu'il y avait déjà tellement de choses.

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.