Salut, j'ai commencé à utiliser la SFML il y a bien longtemps et mon projet s'agrandissant, je me suis rendu compte que la SFML est lente et on m'a clairement dit que la SFML n'était pas une référence pour faire de gros projets avec opengl.
Les appels à glDraw sont lents surtout lorsqu'on utilise pas mal de textures de rendu, SFML n'utilises aucune technique moderne, que ça soit les buffers (UBO, bindless textures, etc...), j'ai donc tenté de changer les classes de la SFML pour faire tout ça, mais ça reste lent, à cause des appels à glDraw à chaque rendertexture, j'ai pensé à utiliser des threads pour faire plusieurs appels à draw simultanément en espérant que ça n'altère pas le rendu final (normalement non car c'est opengl qui se charge de faire la synchronisation au niveau de la mise à jour de l'affichage) et que je n'aie pas trop de crash à cause des accès concurrents, on m'a même carrément conseillé d'utiliser VULKAN plutôt qu'opengl pour faire du multithreading, cependant, SFML ne possède actuellement pas d'implémentation pour VULKAN, je n'en ai pas trouver du moins.
Mais il n'y a pas que ça, j'ai remarqué que plus le CPU est lent à l'exécution, plus le GPU l'est aussi, j'ai remarqué que les fonctions virtuelles (SFML en utilise) sont lentes sur de plus gros projets, parce que, la recherche de la bonne fonction à appeler se fait à l'exécution et non pas en compilation.
J'ai pensé alors à un système de type ECS qui utilise la composition plutôt que l'héritage cependant cela est lourd pour gérer des noeuds (Récupérer les composants de tout les noeuds enfants et calculer la transformation finale) comme c'est illustré dans l'exemple de l'un des tutoriels de la SFML d'ailleurs.
J'ai donc pensé aux nouvelles fonctionnalités du c++ moderne c'est à dire aux templates variadiques et au polymorphisme d'inclusion qui est beaucoup plus rapide d'après mes tests (Malgré le fait qu'il faille rechercher le bon type dérivé à l'exécution mais je le fait à coup de "if" générés en compilation ce qui est rapide) et j'ai implémenté cette solution.
Pourquoi la SFML, n'utilise t'elle pas des fonctionnalités du c++ moderne ? (Et il n'y a pas que la SFML, beaucoup d'ancienne bibliothèque ne le font pas)
Est ce que cela va changer à l'avenir ?
Je pense que si les nouvelles technologies existent, c'est pour certaines raisons, des questions de performance la plupart du temps.
