rewind a écrit 3416 commentaires

On pourrait le résumer comme ça, oui.

Je plussoie. Dans ma nouvelle mouture, j'essaie au maximum de mettre des choses dans des std::vector (et pas des pointeurs, mais des données complètes), qui à utiliser des unions plutôt que de l'héritage, pour justement faciliter le data-driven. C'est une sorte de compromis entre l'ECS pur et l'OO pur.

Tu serais surpris de savoir les jeux AAA qui sont fait avec un système à entités.

Non, je sais que c'est très répandu ;) Mais je sais aussi qu'il y a beaucoup de variantes et que beaucoup croient faire des systèmes à entités alors qu'ils ne font que du data-driven (ce qui n'est pas un mal hein).

Oui mais après, comment l'entité reçoit-elle l'événement ? Peut-elle y répondre ? Les entités sont-elles les seules sources d'événements ? Où mettre le bout de code qui gère l'événement pour une entité (une entité n'est qu'un entier, un composant n'est qu'une donnée) ?

Bref, pas facile.

Je voyais les systèmes un peu comme des modules, un truc assez simple : un système de combat, un système de mouvement, … Avec quelque chose pour enchaîner tout ça. Est-ce l'enchaînement qui est difficile par exemple, parce qu'on a des actions de différentes natures mêlées et que du coup on sort vite de l'exemple "je lance le système de mouvement qui fait bouger tout le monde, puis le système de combat qui fait tous les combats, puis le système de rendu…" ?
Ou avec des systèmes plus fins (juste des fonctions permettant de traiter différents aspects des objets animés, en mouvement, …) est-ce qu'il est trop compliqué de construire des fonctions pour traiter les entités ayant tel ou tel composant plutôt que les considérer globalement ? Par exemple pour savoir comment déplacer un personnage j'ai besoin de ses infos de mouvements mais aussi assez souvent d'autres données qui sont dans un autre composant, ça ne se résumé pas à "telle fonction qui s'applique à n'importe quelle entité possédant ce composant" ?

Je vais donner quelques exemples.

Quand on a une boucle de jeu traditionnelle, on voit bien comment on récupère les entrées (clavier/souris/manettes). Mais dans un système à entités, c'est plus compliqué. Parce qu'il y a plusieurs entités qui peuvent être manipulées par les entrées : le héros, l'interface graphique, une carte, etc. Et du coup, on ne sait pas très bien où récupérer les entrées, et comment les dispatcher vers la bonne entité. Au début, j'avais mis ça dans un système qui mettait à jour un composant du joueur. Mais après, j'ai vu la limite. Donc j'ai mis la récupération des entrées dans un système Player qui mettait à jour le joueur directement, sans passer par un composant. Mais même là, ce n'était pas très satisfaisant pour les raisons précédentes. Et j'étais vraiment bloqué (et je le suis toujours) pour ce mécanisme d'entrée qui peut piloter plusieurs éléments.

Autre exemple, l'affichage. Au début, c'est simple, tu as un système Render qui affiche toutes les entités qui doivent être affichées. Sauf que pour certains trucs, c'est un peu plus complexe. Genre une grande carte d'un monde ouvert, tu veux optimiser l'affichage et n'afficher que les tuiles qui sont à proximité du héros. Une solution, c'est de considérer que chaque tuile est une entité et de faire un système spécial qui va optimiser l'affichage. Sauf que tout n'est pas une tuile. Et puis après, il y a les éléments d'interface (la barre de vie, toussa) qui s'affichent toujours. La vraie solution, c'est d'utiliser plusieurs systèmes de Render qui vont avoir chacun leur caractéristique et qui vont afficher chacun une partie de la scène. Mais du coup, ça complexifie énormément, parce qu'on va avoir des composants différents pour chaque système. Et ces composants sont loin d'être simples. Par exemple, afficher un texte ou afficher une minimap, est-ce le même composant ? Ou deux ? Est-ce le même système qui gère les deux ou deux systèmes différents ?

En vrai, je pense qu'un RPG contient beaucoup trop de diversité et de logique de jeu pour que ce soit faisable dès le premier coup avec un système à entités. Si on part d'un truc existant à transformer, c'est peut-être faisable mais ça demande d'avoir une vision globale de tous les mécanismes et de leurs interactions. Et même après ça, ce ne doit pas être si évident.

Pour répondre à Nicolas Boulay sur le rôle d'un système de gestion d'événements, j'en avais dit quelques mots dans un épisode précédent. Je continue à croire que la gestion des événements est le grand impensé des systèmes à entités. Un système de gestion d'événements est indispensable mais son interaction avec le système à entités n'est jamais explicité et c'est un grand oubli.

librairie est un mot qui existe (même s'il est mal employé dans le cas d'une bibliothèque logicielle), alors que crypter non, ceci explique peut-être cela.

J'adore aussi ce site : cryptage digital.

Notez que mon utilisation indifférente des mots crypté/encrypté traduit un peu mon incompétence, en tout cas ma paresse intellectuelle. En contrepartie, je n'attends pas une réponse détaillée, juste une pointeur vers un tuto pertinent et à jour.

Les mots « crypter » et « cryptage » n’existent pas !

J'avais lu je ne sais plus où qu'il y a tellement d'études dans tous les sens, notamment médicales, qu'il y a une probabilité non négligeable que certaines de ces études se retrouvent justement dans des conditions spéciales qu'on n'observera que là (donc dans les 2% de malchance pour reprendre ton exemple).

Si on sait que a.c dépend de a.h et b.h, alors si a.c a.h ou b.h ont été modifiés depuis la dernière compilation de a.o (il faut mémoriser les timestamps, chose que make fait très bien), et donc il faut recompiler a.o, sinon ce n'est pas nécessaire. Mais c'est peu-être que je n'ai pas compris ce que tu voulais dire par « vrai » dépendance.

La vraie dépendance, c'est à quel projet appartient b.h. Est-ce un en-tête du projet lui-même ou alors est-ce un en-tête d'un projet externe ?

D'après ce journal, il semblerai que Fédora ait des binaires pour windows (je n'ai encore jamais utiliser crossroad, mais il me semble que jehan est quelqu'un d'assez fiable pour le croire :) ).

Oui, j'ai déjà essayé crossroad et j'ai utilisé ces binaires. Le problème avec Windows, c'est que les binaires dépendent du compilateur utilisé (et parfois de la version du compilateur utilisée) à cause des ABI qui changent. Donc des paquets binaires sont forcément liés à un compilateur particulier.

Oui, ça me paraît pas mal comme approche, je note.

Tu ne réponds toujours pas à la première remarque.

Maintenant je ne sais pas si tu cherche à faire un outil de gestion de dépendance tel Ivy ou bower ou si tu cherche à faire un outil de build qui gère les dépendances, mais sincèrement je m'en fou. Tu fais bien ce que tu veux ton langage est suffisamment spécifique, pour que je n'ai jamais a y toucher (que dieu m'en garde).

Alors tu viens troller sur toutes les news concernant les gestionnaires de dépendances pour C++ pour le plaisir ? Certes, tu as dit que Maven ne convenait pas mais tu n'as jamais proposé autre chose qui puisse convenir, tu t'es contenté de dire que faire un nouveau truc en C++, c'était le mal.

L'argument de Barret Michel, c'est de dire que puisque Maven fait déjà le travail de gestion de dépendances, il n'y a pas besoin de coder autre chose. Sauf que je lui ai déjà demandé (et il n'a jamais répondu) pourquoi chaque langage choisissait de refaire son propre outil (et j'ai donné une grosse liste dans un journal précédent) dans son propre langage. Donc soit l'argument de Barret Michel est moisi, soit tous ces devs qui ont fait ce choix sont de gros abrutis.

En plus, dire ça marche chez moi, ça n'est pas tout à fait pareil que de dire que c'est l'outil adapté. Et là aussi, Barret Michel n'a jamais rien répondu aux nombreuses objections qui ont été faites comme quoi Maven n'était pas adapté pour C/C++. Sa seule réponse, c'est de dire que ça doit être possible. Supaire.

Il y a 48 contributeurs à make.

Je croyais qu'on parlait de gestionnaire de dépendances.

Je parle de maturité d'outils.

Il n'y a actuellement aucun outil pour gérer les dépendances en C++ donc aucun outil mature.

Quel est le langage particulier de make, des autotools, de cmake, de gprbuild, etc ?

Les autotools et CMake servent à 99% à gérer C/C++. gprbuild sert à 99% à gérer de l'Ada.

Automake ?

Automake tout seul ne sert à rien et n'est pas un gestionnaire de dépendance.

Pour la gestion des dépendances, comme tu le faisais remarquer gcc -E -M est un bon début.

Ça, c'est bien pour connaître les en-têtes dont dépend un .c mais ça ne dit pas la vraie dépendance.

Pour les bibliothèques, on peut utiliser pkg-config.

pkg-config est une idée super, mais il est très lié à gcc (et aux compilateurs qui utilisent la même syntaxe d'optons). En tout cas, c'est une bonne source d'inspiration sur les concepts de base.

Pour télécharger les dépendances ne pas profiter de celui déjà fournis par nos distributions (pacman, apt, dnf, …), et de leur paquets.

Je suppose qu'il y a un «pas» en trop. Mais après, ça me paraît compliqué, parce que l'idée, c'est aussi de pouvoir compiler sur Windows, et là, pas de paquets.

Tu peux aller voir les discussions précédentes pour trouver des arguments, notamment ceux de Firwen.

Ces arguments vont être mis à l'épreuve dans le cas de biicode qui est en python. On va voir si développer un outil dans le langage qu'il est censé gérer est une bonne idée ou si on peut prendre un autre langage sans risquer de s'aliéner une énorme partie de la communauté. Mais j'imagine bien le résultat (au vu de tous les autres outils similaires dans les autres langages) : biicode ne sera pas développé alors que pourtant, python c'est tellement plus mieux que C++ pour développer ce genre d'outils (remplace python par ruby, java, C# ou autre, selon ton bon vouloir). Le futur nous le dira assez vite.

On a déjà eu cette discussion ailleurs mais on peut recommencer. L'argument qui consiste à dire qu'on utilise le langage le plus approprié pour une tâche se heurte à une impasse dans ce genre d'outils qui doit gérer un langage particulier. Parce qu'outre le fait de devoir se traîner une autre pile logicielle (et dans le cas d'un développeur, la première prend souvent déjà beaucoup de place), il faut trouver l'intersection des développeurs entre les deux langages, et même en prenant des langages aussi répandus que C++ et Python, ça n'est pas gagné. Il n'y a aucun contre-exemple digne de ce nom (c'est-à-dire largement utilisé) dans aucun langage.

C'est un peu plus complexe que ça, il l'a dit mais il ne l'a pas dit et pas comme ça et pas au début.

Source ? Parce que les universités qui sont en déficit, elles sont placés sous tutelle.

leur position en grêce qui bloque un pipeline "sud" qui permettrait de bypasser la russie

Il ne permet pas de bypasser la Russie puisque le pipeline démarre en Russie. En revanche, il permet de bypasser l'Allemagne puisqu'actuellement, tous les pipelines arrivent en Allemagne.

J'ai utilisé le mot du journal. Sans doute que le monsieur du journal soutient les dit partis souverainistes et donc refuse de les appeler "extrême-droite".

Toi tu y vas fort sur les amalgames et les approximations… Je te résume :

• gros chiffre qui fait bien peur mais qui n'est pas sûr
• immigrés = travailleurs au black
• immigrés = délinquants

Et après, tu crains que ça fasse le jeu de partis souverainistes ? Mais il faudrait déjà que tu n'adoptes pas les "raisonnements" moisis de ces partis là.

Ce que tu décris, ça peut se faire avec une ligne de shell avec gcc -E -M main.c et ça va marcher pour les programmes simples.

Ils n'ont pas une grosse communauté. Ils ont surtout bénéficié d'une publicité sur plein de gros sites qui fait que chaque fois que quelqu'un demandait un gestionnaire de dépendance, c'était la réponse automatique (même si celui qui donnait la réponse ne l'utilisait pas lui-même). Et puis, avec une annonce comme ça, ça ne va pas rassurer la communauté, parce que pour l'instant, rien ne garantie que le service va continuer sur le moyen terme. Il existe des alternatives qui ont eu moins de pub et une petite communauté également (et qui souffrent d'autres problèmes).

Oui, remettons des humains partout, et revenons aux 18è siècle, c'était tellement mieux…

18è siècle ? Ha ouais, on en est là. Tu en as d'autres des comme ça ou c'est juste pour le plaisir de nous faire mourir de rire devant un argument aussi foudroyant…