Et puis le deuxième problème, c'est qu'il faut l'entité associée au composant et si tu parcoures les composants tels quels, tu auras du mal à savoir quelle est l'entité correspondante.
Justement, sur un système "monocomposant", tu n'as pas à connaitre l'entité associée.
Après y avoir réfléchi tout l’après midi, je pense que tu as raison. J'ai accroché sur ta phrase où tu parles d’optimisation par rapport au cache mais en fait c'est loin d'être important. Tu auras plein d'autre problème de perf avant de devoir régler celui la.
En vrac on peut citer :
En opengl, ce qui coute cher, c'est le changement de contexte[1]. Typiquement changer la texture, le mesh ou le program (shader) courant (Il faut tj se rappeler qu'opengl est une machine à états, qui plus est distante car sur la carte graphique). La difficulté sera d'ordonner les rendus pour limiter ces changements (La vrai difficulté sera quand des objets partageront certaines textures et d'autres partageront certains mesh, le tout de manière non homogène. Faut-il limiter les changements de texture ou les changements de mesh ?).
Pour le moteur physique ce sera comment gérer l’interaction entre les éléments. Typiquement, pour ton exemple des balles rebondissantes, comment rajouter les collisions entre les balle ? Comment trouver les balles proches de celle actuellement traitée sans parcourir toute la liste ?
Si tu dois optimiser ta lib, pose toi ces questions là avant de voir les problèmes de cache. (En gros continue ce que tu fais :) )
[1] De manière surprenante, les articles et moteur 3D "basique" ne prennent absolument pas ce fait en compte. Ils ordonnent le rendu des objets pour faire les plus proches en premier et ainsi éviter de dessiner complètement les objets qui seront cachés ensuite par d'autres. Mes tests m'ont montrer que ce n'était pas vraiment là qu'il fallait optimiser. (Ça fait quelque temps que j'ai pas regardé les articles sur le sujet, ça a peut être changer entre temps.)
Dans un de mes anciens projets pro (qui a était annulé faute de budget. :( ). Une des optims qui était prévu était de faire le rendu en deux passes :
Une première classique qui parcourrait les entités dans l'ordre où elles viendraient. Par contre au lieu de faire le rendu directement, elle remplirait une liste de "commande d'affichage" (mesh, program, texture, ... à utiliser)
La deuxième, trierait cette liste pour limiter les changements de contexte et ferait le rendu réelle en parcourent la liste triée.
[^] # Re: Duck typing et implementation
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
Justement, sur un système "monocomposant", tu n'as pas à connaitre l'entité associée.
Après y avoir réfléchi tout l’après midi, je pense que tu as raison. J'ai accroché sur ta phrase où tu parles d’optimisation par rapport au cache mais en fait c'est loin d'être important. Tu auras plein d'autre problème de perf avant de devoir régler celui la.
En vrac on peut citer :
En opengl, ce qui coute cher, c'est le changement de contexte[1]. Typiquement changer la texture, le mesh ou le program (shader) courant (Il faut tj se rappeler qu'opengl est une machine à états, qui plus est distante car sur la carte graphique). La difficulté sera d'ordonner les rendus pour limiter ces changements (La vrai difficulté sera quand des objets partageront certaines textures et d'autres partageront certains mesh, le tout de manière non homogène. Faut-il limiter les changements de texture ou les changements de mesh ?).
Pour le moteur physique ce sera comment gérer l’interaction entre les éléments. Typiquement, pour ton exemple des balles rebondissantes, comment rajouter les collisions entre les balle ? Comment trouver les balles proches de celle actuellement traitée sans parcourir toute la liste ?
Si tu dois optimiser ta lib, pose toi ces questions là avant de voir les problèmes de cache. (En gros continue ce que tu fais :) )
[1] De manière surprenante, les articles et moteur 3D "basique" ne prennent absolument pas ce fait en compte. Ils ordonnent le rendu des objets pour faire les plus proches en premier et ainsi éviter de dessiner complètement les objets qui seront cachés ensuite par d'autres. Mes tests m'ont montrer que ce n'était pas vraiment là qu'il fallait optimiser. (Ça fait quelque temps que j'ai pas regardé les articles sur le sujet, ça a peut être changer entre temps.)
Dans un de mes anciens projets pro (qui a était annulé faute de budget. :( ). Une des optims qui était prévu était de faire le rendu en deux passes :
Matthieu Gautier|irc:starmad