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 ).