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 ?).
Je fais confiance à SFML pour ça. Il y a des trucs dans SFML qui me font dire que c'est bien foutu à ce niveau là. Ou plutôt pas trop mal foutu.
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 ?
Je crois que je vais étendre ce petit tutoriel pour montrer comment on fait : on utilise ce qui marche déjà. En l'occurrence, des moteurs physiques 2D, il n'y en a pas 50 et on tombe très vite sur un qui est très utilisé (je crois d'ailleurs que c'est celui qui est utilisé dans Newton Adventure). Je crois que ça fera partie d'un de mes prochains articles de la série.
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.
C'est une technique intéressante, j'y réfléchirai le moment venu.
En tout cas, ça fait plaisir de voir tes commentaires qui mettent un peu la pression ;) N'hésite pas à continuer.
[^] # Re: Duck typing et implementation
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é à 3.
Je fais confiance à SFML pour ça. Il y a des trucs dans SFML qui me font dire que c'est bien foutu à ce niveau là. Ou plutôt pas trop mal foutu.
Je crois que je vais étendre ce petit tutoriel pour montrer comment on fait : on utilise ce qui marche déjà. En l'occurrence, des moteurs physiques 2D, il n'y en a pas 50 et on tombe très vite sur un qui est très utilisé (je crois d'ailleurs que c'est celui qui est utilisé dans Newton Adventure). Je crois que ça fera partie d'un de mes prochains articles de la série.
C'est une technique intéressante, j'y réfléchirai le moment venu.
En tout cas, ça fait plaisir de voir tes commentaires qui mettent un peu la pression ;) N'hésite pas à continuer.