j'ai pas tout lu.
Mais dans ton nouveau code tu mélanges des shader aussi et ça alourdi pas mal.
Les shader gèrent le traitement de des données (ici, le pipe graphique) et sont indépendant de la soumissions des données (immediate mode, display list, vbo, ...)
Après, je me permet une remarque (et je me trompe peut-être car je n'ai pas tout le code sous la main), mais dans ton code d'origine, j'ai l'impression que tu parcours ton data model pour faire l'affichage.
C'est là que ta séparation code/donnée est mal faite !
Dans ton parcours de data model, tu dois construire un noeud de scenegraph avec seulement les infos utiles pour le rendu :
une seule matrice de transformation (tu la calcules à ce moment précis)
Ton mesh (les vertex avec tous leurs attributs)
Les données supplémentaires (reference vers une texture à bind, shader particulier à utiliser...)
Les states OpenGL dont tu as besoin (material, lights, ...)
Ton rendu se fait ensuite en parcourant ton scenegraph, appliquand le state, la matrice de transformation et soumettant les données.
Ça c'est pour un scene graph simple (sans effet compliqué de lumière, transparence, ...) et sans essayer de minimiser les changement d'états d'OpenGL qui coutent très cher.
Tu peux alors mettre à jour juste une partie de ces données (une entité de ton jeu met à jour son noeud dans le scene graph)
Tu peux également faire le rendu dans un thread distinct pour garder un framerate constant et utiliser un lock sur les noeuds que tu mets à jour (ou construire un noeud à coté et juste faire un remplacement quand il est fini)
Et tu retrouve un "logique" qui ressemble à du direct mode dans ton code "de dessin" qui est en fait le code de création d'un noeud de scene graph tout en ayant un rendu optimisé et surtout découplé du reste du code, donc facile à faire évoluer.
Après, c'est peut-être ce que tu fais déjà avec ta classe Sprite et je l'ai mal compris juste.
[^] # Re: OpenGL antique
Posté par moi1392 . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 6.
j'ai pas tout lu.
Mais dans ton nouveau code tu mélanges des shader aussi et ça alourdi pas mal.
Les shader gèrent le traitement de des données (ici, le pipe graphique) et sont indépendant de la soumissions des données (immediate mode, display list, vbo, ...)
Après, je me permet une remarque (et je me trompe peut-être car je n'ai pas tout le code sous la main), mais dans ton code d'origine, j'ai l'impression que tu parcours ton data model pour faire l'affichage.
C'est là que ta séparation code/donnée est mal faite !
Dans ton parcours de data model, tu dois construire un noeud de scenegraph avec seulement les infos utiles pour le rendu :
une seule matrice de transformation (tu la calcules à ce moment précis)
Ton mesh (les vertex avec tous leurs attributs)
Les données supplémentaires (reference vers une texture à bind, shader particulier à utiliser...)
Les states OpenGL dont tu as besoin (material, lights, ...)
Ton rendu se fait ensuite en parcourant ton scenegraph, appliquand le state, la matrice de transformation et soumettant les données.
Ça c'est pour un scene graph simple (sans effet compliqué de lumière, transparence, ...) et sans essayer de minimiser les changement d'états d'OpenGL qui coutent très cher.
Tu peux alors mettre à jour juste une partie de ces données (une entité de ton jeu met à jour son noeud dans le scene graph)
Tu peux également faire le rendu dans un thread distinct pour garder un framerate constant et utiliser un lock sur les noeuds que tu mets à jour (ou construire un noeud à coté et juste faire un remplacement quand il est fini)
Et tu retrouve un "logique" qui ressemble à du direct mode dans ton code "de dessin" qui est en fait le code de création d'un noeud de scene graph tout en ayant un rendu optimisé et surtout découplé du reste du code, donc facile à faire évoluer.
Après, c'est peut-être ce que tu fais déjà avec ta classe Sprite et je l'ai mal compris juste.