Forum de la communauté SFML
Aide => Graphique => Discussion démarrée par: janf le Décembre 22, 2015, 06:52:17 pm
-
Bonjour,
Je sais que le sujet des performances a déjà été abordé ici. La solution, pour dessiner des choses à l'écran sans trop perdre en images par seconde, c'est d'utiliser un nombre minimum de sf::VertexArray plutôt que d'afficher plein de sprites. Je cite : "les performances sont directement proportionnelles au nombre d'appels à draw..." J'avais déjà pu tester que d'afficher un sprite par tile dans une tilemap réduisait drastiquement les performances.
Aujourd'hui j'ai fais un petit test en affichant une image en deux tableaux de vertices. Elle représente le terrain, ou la map, c'est un simple dessin sous paint. Le premier tableau représente le sol, le deuxième ce qui pourra être affiché par-dessus le personnage. Entre les deux je dessine le sprite, donc.
Je voudrais savoir s'il est normal que chaque appel à draw pour un VertexArray divise mon fps par environ deux ?
Pour le coup j'ai fait un autre test en rajoutant une dizaine de sprites et ça a moins d'impact que l'ajout d'un seul VertexArray.
Loin de moi l'envie de dénigrer la SFML, c'est une bibliothèque que j'aime beaucoup, mais je voudrais savoir, n'étant pas du tout professionnel ni très expérimenté, si ce comportement est comparable avec celui des technologies utilisées dans les jeux 2d commerciaux, si les développeurs professionnels doivent composer avec les mêmes contraintes ? Outch la phrase à rallonge. Donc voilà, j'ai mis des petites images pour étayer mes propos et vous montrer mes talents de dessinateur Mspaint approved.
Merci d'avance à ceux qui pourront me répondre.
Voici mes tests (j'utilise une carte graphique récente avec accélération 3d) :
(http://exiledtgc.free.fr/img/screen2.png)
Ici je dessine tout. J'ai un FPS de 108ms.
(http://exiledtgc.free.fr/img/screen3.png)
J'enlève un VertexArray
(http://exiledtgc.free.fr/img/screen4.png)
J'enlève les deux.
Voici ce que contiennent les VertexArray, et comment je les rempli, au cas où ça puisse avoir un impact sur les perfs :
(http://exiledtgc.free.fr/img/map.png)
(http://exiledtgc.free.fr/img/mask.png)
(http://exiledtgc.free.fr/img/screen5.png)
-
Les conseils des tutoriels c'est bien, mais il ne faut pas en oublier le bon sens pour autant... Si un vertex array contient un million de points, c'est un seul appel à draw() mais qui va tout de même coûter bonbon. Et vu comment tu remplis les tiens, je pense qu'ils sont assez chargés.
-
Ah bah oui, tout à fait! Ma fenêtre et ma map sont en 800x600. Le 2ème array ne contient que la baraque, donc le 1er qui affiche le reste est chargé de pas mal de points oui. Bon, même 800x600 ça fait pas des millions. Je me disais que peut-être un quad texturé coutait autant que son équivalent en points.
La bonne stratégie serait donc d'utiliser un autre type de primitive, c'est ça ?
-
Bon, même 800x600 ça fait pas des millions
Ca en fait tout de même un demi (480000) ;)
Je me disais que peut-être un quad texturé coutait autant que son équivalent en points.
Compare par toi-même :
- 480000 points à transformer, 480000 pixels à colorer
vs
- 4 points à transformer, 480000 pixels à colorer
Si on prend la très grossière approximation que chaque étape prend autant de temps, une solution est 2x moins performante que l'autre.
La bonne stratégie serait donc d'utiliser un autre type de primitive, c'est ça ?
Difficile de te conseiller sans savoir réellement ce que tu comptes faire. Parce qu'un vertex array composé de points représentant chacun un pixel... j'espère que c'est pour faire des tests, et que ce n'est pas ce que tu vas faire dans ton appli finale ;)
Je ne peux que te conseiller de chercher des articles expliquant le pipeline de rendu graphique (ce qui se passe à l'intérieur de la carte graphique), ça te permettra de mieux appréhender les questions d'optimisation.
-
Oui tout à fait, je ne fais que m'exercer pour le moment. Effectivement vu comme ça il est plus raisonnable d'utiliser un quad. J'avais pas percuté le concept de transformation appliqué à chaque élément du tableau.