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.
[^] # Re: Composants
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Faut pas commenter une news si ancienne ! J'ai failli ne pas voir ton commentaire ;)
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).
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.