conception et programmation ECS

Citation:

---

des unordered_map sont très (très(très)) lentes. Voilà pourquoi il peut être intéressant d'utiliser des vectors pour stocker tes Components, fut-ce au prix de l'héritage.

---

Oui. Il faudra a terme que je transforme mes std::unordered_map en std::vector. Pour l'instant, c'est pour les test et l'élaboration de mon programme, un map est très pratique. comme disait Donald Knuth

Citation:

---

premature optimization is the root of all evil

---

Pour l'instant je me contente d'essayer de faire un programme qui marche. Par contre, je ne vois absolument pas le rapport avec l’héritage? Un std::vector fonctionnerait de la même facon qu'un map, sauf qu'au lieu d'utiliser find, on utiliserait find_if , avec tout le bazar qui va avec pour qu'on puisse trouver un objet par son id...

Citation:

---

les Components sont stockés dans les System ?

---

Non, ils sont stockés dans l'Engine. Ce sont des références que les Systems utilisent ( dans mon cas, et là j’avoue que personne ne m'a dit ce qu'il en pensait, mais on m'a clairement dit que les Systems pouvaient utiliser des ptr/ref sur les containers de composants, l'important étant que les composants soient stockés en "dure" dans des vector afin, d'être côte à côte dans la mémoire ).

Citation:

---

Par contre, je ne vois absolument pas le rapport avec l’héritage?

---

Parce qu'il n'y en a pas :)

Citation:

---

mais on m'a clairement dit que les Systems pouvaient utiliser des ptr/ref sur les containers de composants

---

Mouais, ça peut être intéressant si tu utilises des smart pointer je pense, mais comme je te l'ai dit, un déférencement prend du temps. Il sera plus rapide (et plus lisible) de stocker l'index du Component, plutôt qu'un pointeur vers lui.

peut être.

Mais pourquoi parles tu de "déréférencement" ?

Quand un System parcourt un container, il le fait directement, ( sauf erreur ), étant donné qu'il est en référence. Il a juste à se "positionner" au début du container, après il est censé lire les données les unes à côté des autres, enfin ca paraîtrait logique...? Mais tout cela dépasse très largement mes connaissances, donc je n'ai aucune certitude à ce sujet...

Citation:

---

Quand un System parcourt un container, il le fait directement, ( sauf erreur ), étant donné qu'il est en référence. Il a juste à se "positionner" au début du container, après il est censé lire les données les unes à côté des autres

---

Oui, mais si tes System stockent des références sur Component, cela ralentira les update parce qu'il faudra déréférencer ( ;) ) les pointeurs, avant de modifier les variables directement.

En fait il est plus rapide d'effectuer ceci :

Code:

---

1 2 3

std::vector<int> vector1; ... vector[7]++;

---

que ceci :

Code:

---

1 2 3

std::vector<int*> vector2; ... *(vector2[7])++;

---

Bon, mais "premature optimization is the root of all evil", concentre toi d'abord sur l'architecture de ton ECS :)

Oui, en effet, utiliser des pointeurs diminue les perfs. C'est même pour cela que le ECS est censé être plus efficace : les composants, eux, ne sont pas des pointeurs. Ils sont des données rangés les unes à côtés des autres.

En revanche, quand tu cherche un composant, tu utilise un ittérateur, la plupart du temps, or celui ci est un pointeur. Mais quand il va s'incrémenter pour une boucle, par ex, il va passer simplement d'une adresse à celle qui est juste à côté ( enfin je suppose ), donc c'est ok. Contrairement à un vector de pointeur, par ex, qui va passer d'un adresse 0017, par ex, à une adresse 9754 ce qui prendra plus de temps, alors que son ittérateur est simplement incrémenté.
Mais je ne suis pas sur de ce que j'avance, alors je me trompe peut être.

Quoi qu'il en soit, comment fais tu pour utiliser plusieurs Systems en même temps sur ton vector ? Il faut forcément à un moment donné qu'ils l'aient en référence ou en pointeur. A moins que tu n'ai qu'un système qui contient le vector...( ce qui est plus du ECS j'imagine ).