Tableau fixe de sprites

[lezebulon]

Salut

J'ai une question d'ordre général sur l'optimisation et je voudrais votre avis.
En gros dans mon moteur de RPG 2D le jeu est divisé en maps. Un nombre arbitraire de maps peuvent être à l'écran à la fois (si on dézoome à fond).
Chaque map a un nombre fixe de cases (60x60 = 3600), et actuellement chaque case possède les éléments suivants:
- pointeur sur un objet tile qui me donne les propriétés de la case (collision etc)
- sf::sprite pour afficher la case

Le pb est que même si sf::sprite est léger, j'arrive rapidement à ~150 Mo de mémoire bouffée par tous les sf::sprite.

Donc à votre avis comment faire pour réduire la taille totale prise par la mémoire? J'ai pensé créer une nouvelle classe qui hérite de sf::drawable mais pas de sf::transformable, vu que c'est de là qui vient la plus grosse partie de l'objet

[Laurent]

Mets tout ton niveau dans un gros sf::VertexArray.

[lezebulon]

Du coup je suis obligé de dessiner tout le vertex array d'un coup non?

[Laurent]

Oui, du coup tu auras de bien meilleures performances.

[lezebulon]

Euh ouais mais en théorie je ne dessine que les sprites qui sont dans ma vue, soit ptet 30% de ceux qui sont dans une map.
Enfin bref je verrai chez moi ce soir pour les vertex array, je connaissais pas mais je peux surement adapter à mon cas

[Laurent]

Euh ouais mais en théorie je ne dessine que les sprites qui sont dans ma vue, soit ptet 30% de ceux qui sont dans une map.

Je pense que tu auras tout de même de meilleures performances. Ce qui limitait SFML avant c'était le nombre d'appels OpenGL (donc le nombre d'appels à la fonction draw) et non pas le nombre de triangles affichés.

[kamui]

Bonjour,

est-ce que ça veut dire que si on renferme toutes nos méthodes style draw et display dans le scope d'une condition qui attend qu'un temps x soit écoulé avant d'être vraie, on aura toujours un si bon affichage (à condition de rester dans un laps de temps qui donne l'illusion de la continuité) mais des perfs bien meilleures ?

Si je suis pas clair désolé.

[Laurent]

Oui mais bon, si tu dois attendre pour dessiner ça veut dire que tu as déjà des performances suffisantes

[kamui]

Ouep 

Mais c'est dans le cas ou autre chose (à priori bien codé) effectue un traitement très très lourd, je cherche du coup où on peut faire des économies..

pour être moins mystérieux, je penses utiliser le nouveau moteur d'éclairage présenté par Gregouar dans les projets SFML, et apparemment c'est un moteur gourmand, sur lequel je ne pourrais malheureusement pas vraiment gagner en performances.

[Laurent]

Tu gagneras en performances si tu peux découpler le truc qui prend du temps de l'affichage (calculs de logique ou de collisions par exemple). Or ici je ne pense pas que ce soit le cas

[kamui]

Ok, donc va falloir que je mette les mains dans le cambouis  avec tout ce que j'ai à faire déjà  .

Merci pour les infos en tout cas.
 

[lezebulon]

Mets tout ton niveau dans un gros sf::VertexArray.

Hello
je uppe 3 mois après....
en fait comment je dois faire concrètement? J'ai mon tableau de sf::texture (qui part normallement dans un tableau de 60x60 sf::sprites), comment je fais pour faire un seul objet sf::VertexArray qui affiche toutes les textures collées selon ma grille?

[Laurent]

Un seul VertexArray implique forcément une seule texture. C'est justement pour ça que tu gagnes en performances, tu peux tout afficher en un seul appel OpenGL.

Il faut donc tout regrouper, si tu le peux, dans la même texture.

[lezebulon]

Là où je pige pas c'est que je vois pas de sf::texture dans vertexarray, du coup comment je lui assigne une texture?

[Laurent]

window.draw(vertexArray, texture);