Javaquarium et conception

Pour modifier l'implémentation oui, pour modifier le type de retour et donc la signature de la fonction non. Sinon le code utilisateur arrêtera de compiler quand il passera à C++14, et c'est pas terrible.

Un truc du genre

1
2
3
4
5
6
7
8

std::set<Component *> has(Entity entity, Component const & component)
{
#ifdef CPP_2014
    return without_cast;
#else
    return with_cast;
#endif
}

ben en l'occurrence, y'a pas besoin du cast même en C++11 si tu retournes un std::set<Component*>.

Je suis embrouillé. Non, un bool à la place. Comme ton exemple en gros, avec juste un test pour savoir si on est en C++11 ou C++14.

Dans ce cas, oui, pourquoi pas .

Si c'est juste pour mettre un const_cast derrière un #if, je dirai de ne pas te prendre le choux.

Par contre, pour les macros, ça ne marche pas comme ça. Chaque compilo a une matrice de compatibilité qui lui est propre en fonction de sa version. Je conseillerai plutôt de demander à la chaine de compilation (CMake ou autotools) de détecter quels features du C++11 ou 14 sont supportés. De là, déclare dans un fichier config.in.h ce qui mettra de quoi générer (ou pas) le #define que tu pourras tester dans ton code. Cf ce que j'avais fais pour mon solveur de ricochet robot.

Ce sujet est intéressant. Je cherche à faire la même chose qu'informaticienzero en Java (je connaissais à peine le langage et je souhaite savoir l'utiliser même si je ne l'aime pas trop).

Est-ce que c'est possible de voir ton code en entier ? Sur GH ou équivalent de préférence

Parce que j'ai tenté quelque chose mais je bloque à un endroit en particulier.

Sinon, j'ai pas trouvé d'équivalent pour faire entity.get<ComponentType>() et je trouvais ça moche de faire entity.has(ComponentType component) puisque je dois dans ce cas envoyer une instance de ComponentType (ComponentType étant par exemple BreedingType, Race ou FeedingType pour en revenir à l'aquarium). En fait chaque type de composant pourrait être une énumération… Comme enum FeedingType { None, Carnivorous, Herbivorous };

D'ailleurs, j'ai créé un sujet ici.

À propos, pour le tuto sur l'ECS qui est en cours (d'après ce que j'ai entendu), est-ce que le Javaquarium ne serait pas un parfait "projet fil rouge" ?

C'est ce que j'ai pensé. Et j'ai l'impression que l'intérêt de l'ECS se révèle encore plus en C++ qu'en Java. Le tuto va peut-être donner des morceaux de codes dans plusieurs langages.

Il y a pas mal d'articles sur l'ECS en Java. Les ECS viennent pallier à un problème de conception inhérent à la COO. Java ne peut que être impacté…

Il y a pas mal d'articles sur l'ECS en Java.

C'est intéressant. J'y avais pas pensé, je vais chercher pour le Java.

Mon code en C++ est ici, mais je n'ai pas beaucoup avancé depuis. Il faut que je m'y remette.

Ok, merci. Je suis un peu perdu en ce qui concerne l'ECS et ça m'aide de voir ta version (même si elle est qu'entamée). Je pense que je vais aussi suivre le conseil de B0ucEtMystere. Tout ça me donne affreusement envie de le faire en C++, mais j'ai décidé de me faire la main avec Java.

Ton Store pourrait se transformer en Pool si jamais tu décides de réutiliser le code pour un jeu plus gourmand. J'ai un pote qui a fait un Danmaku avec un ECS simplifié et une Pool, les résultats sont impressionnants. C'est une technique qui évite les Cache Miss, si ça te dit quelque chose (peut-être même que tu sais déjà tout ça). Sans ça, il tournait à 20 FPS avec 1000 entités. Avec, il est passé à 60 FPS avec 1 000 000 d'entités (c'est à peu près les chiffres).

Nope, je n'ai entendu parler des pools que vraiment rapidement. Je vais regarder de plus près. Mais là je t'avoue qu'il va falloir que je revois un paquet de choses pour me remettre dans le bain.

Si les pools t'intéresse, je te conseille de terminer Javaquarium avant parce que les deux patterns ne sont pas évidents à maitriser J'en ai parlé mais moi-même je ne sais pas trop comment ça fonctionne, c'est un ami qui m'en a parlé et qui m'a résumé comment il avait fait.

Ce qui a participé à optimiser autant son code est aussi la gestion des graphiques avec une "grille". À la manière d'une carte découpée en carrés. Du coup, il ne vérifie les éventuels collisions d'une entité qu'avec celles qui sont dans le même carrés (ou au moins qui "chevauche").

M'enfin, concentrons-nous sur Javaquarium. Moi je verrais ça plus tard

Je réponds @ lmghs (un peu tard, je sais) : en C++, l'ECS fonctionne particulièrement bien avec la Pool. la Store d'informaticienzero peut très bien tendre vers une pool et le tout permet de gagner beaucoup en performance. En Java, ça n'a un intérêt quasiment que structurel : ça permet un code modulable et évolutif, tout en étant efficace. Mais ça ne permet pas vraiment de gagner en performance vu que tu ne gères pas la mémoire (les objets peuvent être n'importe où dans la mémoire, même si j'imagine que la JVM fait des optimisations pour limiter les Cache Miss).
Pour les mêmes raisons, la pool en Java me parait pas très utile.

D'où ma phrase tout à l'heure (je ne disais pas que c'est inutile en Java) :

Et j'ai l'impression que l'intérêt de l'ECS se révèle encore plus en C++ qu'en Java.

Les ECS, c'est pas qu'une question de pools & cie. C'est aussi une question de dispatcher les traits. Quand un objet va avoir plusieurs traits, certains connus statiquement, d'autres rajoutés ou supprimés dynamiquement, et que le comportement va être fonction des traits disponibles (vision dans le noir, résistance au poison, allergie au soleil, …), les ECS aident aussi.

Oui bien sûr. J'en suis conscient et c'est ce qui m'a séduit dans l'ECS. Je dit ça pour appuyer le fait que ça ajoute un intérêt à l'ECS pour le C++ par rapport au Java ou n'importe quel langage de ce style.