[SFML 2]Tile mapping lent

[Tourpi]

Bonjour

Ca fait pas mal de temps que je connais la SFML et j'ai voulu essayé la version 2 rapidement.
J'utilise alors pysfml mais le problème ne vient pas du binding je pense.

J'ai voulu faire un jeu 2D en vu de dessus. J'ai fini presque fini la partie navigation et lors de mes recherches de sprites, je trouvais souvent des images entières de maps à afficher. Au début, j'utiliser la méthode de tile mapping puis je me suis retrouver rapidement à souffrir au niveau des FPS (c'est exagéré mais je voyais bien que je perdais un peu de vitesse avec des maps de plus en plus grandes). J'ai pensais que cela venait de python qui pouvait être un poil lent et ne pouvait pas tenir la cadence maximal.

J'ai eu un doute lorsque ma recherche sur internet ne montrait pas vraiment de problème de lenteur. Je me suis donc dit que c'est simplement mon code qui était pourri.
J'ai donc refait une nouvelle architecture en plusieurs threads (un pour l'affichage, un pour le son et un pour les évènements). J'affichais dès le début des maps entières trouvé sur internet.
Cette fois-ci je n'ai pas eu de problème de lenteur.

J'ai alors voulu aller plus loin de me faisant un editeur de niveau car je voulais d'autres maps. Je suis donc repartis sur le tile mapping et pour eviter de ralentir trop l'affichage, je précompilais les maps. En effet, j'ai plusieurs couches d'affichages et ma précompilations permettait de superposer tous les sprites et de recréer un tileset + map avec les nouveaux sprites créer. Donc je n'avais que un seule sprite a afficher par case.

Je lance le programme et je constate qu'il y a à nouveau des ralentissements. Je modifie mon code de précompilation de map pour qu'elle génère l'image entière de la map. Cette fois-ci, il n'y a pas de ralentissement.

Je pense que même si le code est pourri à la base, le changement entre les deux versions montrent bien un problème. En effet, les seules bouts de code qui changent sont exécuté pendant la précompilation et pendant l'affichage. Et celui de l'affichage transforme simplement un app.draw(world) en app.draw(world[x, y]) dans une boucle.

Donc je voulais savoir si il y avait déjà eu des problèmes de ralentissement pareil et ce que vous pensez du problème. Je pensais que le tile mapping permettait justement d'être plus rapide mais je remarque le contraire.

[G.]

Est-ce que tu draw uniquement les tiles qui sont présentes dans ta vue / écran ?

[Tourpi]

Je dessine que ce qu'il y a dans l'écran avec un contour de deux case en plus (pour prévoir mes animations de déplacement).
Donc ça reviens dans mon cas a dessiner 10 * 10 images (et le joueur). Je trouve que c'est vraiment peu.

[LD_FLO]

Tu limites tes FPS avec "setFramerateLimit()" ou "setVerticalSyncEnabled()" ? Parce que la première est sujet à quelques dysfonctionnement,  essaie "fenetre.setVerticalSyncEnabled(true)". Vu ton cas, il n'y a aucunes raisons à l'apparition de ralentissements.

[Tourpi]

J'ai la  synchro verticale déjà activé. J'avais essayé avec le framerateLimit à 24 et c'était mieux car je ne voyait pas de différence entre une grosse carte et une petit (avant j'avançais avec le framerate) mais j'ai vite abandonné car c'était encore basique et si je devait déjà limiter le framerate au minimum possible dès le début, ça n'allait pas le faire.

[LD_FLO]

Etrange, envoie ton code python (simplifié), ça vient peut être de là

[Tourpi]

Voici ma fonction d'affichage de la fenetre simplifié. Elle est appelé par la méthode run de mon thread d'affichage :

def paintEvent(self):
        self.app.clear()
        self.states.transform = sf.Transform().scale((self.scale, self.scale))
       
        ### ...
        ### ...
        ### Gestion de l'animation et du scrolling de la map par rapport au mouvement du personnage
       
        # Gestion du scolling de la map par rapport à la position du personnage
        x, y = self.game.player.position
        xMin = int(x - self.nbrTileX / 2.0) + 1
        yMin = int(y - self.nbrTileY / 2.0) + 1
        self.states.transform.translate((-xMin * self.tileWidth, -yMin * self.tileHeight))

        # Affichage avec une image de fond
        self.app.draw(self.worldSprite, self.states)
       
        # Ou affichage avec des tiles
        for x in xrange(self.nbrTileX + 4):
                for y in xrange(self.nbrTileY + 4):
                        if (x + xMin - 2, y + yMin - 2) in self.game.world:
                                self.app.draw(self.game.world[x + xMin - 2, y + yMin - 2].sprite, self.states)
               
        #Affichage du joueur
        self.app.draw(self.animPlayer[self.game.player.movement][self.game.player.direction], self.statesPlayer)
       
        # Affichage d'une couche supérieur
        if self.worldSpriteSup:
                self.app.draw(self.worldSpriteSup, self.states)
               
        self.app.display()
 

La seule chose qui change entre l'affichage d'un background et celle des tiles c'est les lignes d'affichages (à part le chargement.
Mes sprites ne bougent pas et j'utilise un RenderStates pour gérer le scrolling.
Peut être que l'utilisation de ça ralenti un peu la sfml ?

[LD_FLO]

self.nbrTileX et self.nbrTileY valent environ combien ?

[Tourpi]

Ils valaient 10 quand j'ai testé. La je l'ai monté à 30 et ça passe bien avec le background. J'imagine même pas avec les tiles

[LD_FLO]

Ah oui, il y a quelque chose qui te ralentit c'est sûr tu m'aurais dit 2000, ça aurait été le problème.
Si je comprend bien, ta map est constituée de petits carrés que tu affiches ?

[Tourpi]

Oui. Un seule petit carré par case. C'est pour ça je trouve que c'est bizarre.
Ca me fait que 14 * 14 = 196 affichage (avec les bords). Donc je comprend pas pourquoi c'est si lent.

C'est pour ça que je me posais des questions sur les RenderStates. Peut être sont ils lourd à utiliser ?

Sinon ça pourrait être python mais ça m'étonnerais quand même qu'il ne sache pas compter jusqu'à 200 rapidement.

[LD_FLO]

J'ai eut programmé un jeu en python avec la bibliothèque SDL (qui est assez lente niveau affichage), et il est vrai qu'il en faut peu pour faire chuter les FPS, mais 200 petits carrés, c'est pas censé être aussi lent, faut pas déconner.
Je vois pas pourquoi tu utilises les RenderStates. Affiche tes tiles comme des sprites normaux. C'est peut être ça le problème

[Tourpi]

Mes sprites ne bougent pas. Il reste a l'emplacement de la carte. J'utilise alors un RenderStates pour translater toute la carte pour faire le scrolling.
Si j'enlève le RenderStates, il faut que dans ma boucle d'affichage des tiles, je change constamment la position.

Je trouve que ça reviens au même mais je préfère la solution avec le RenderStates. C'est plus propre je trouve.

Je vais essayer avec l'autre solution et voir si il y a des bons résultats.

[LD_FLO]

Pourquoi tu n'utilises pas les caméras ? Ça t'éviteras toutes ces opérations, plus besoin de faire bouger ta map, tu fais bouger ton personnage, et la caméra le suit.

[Tourpi]

En effet. Ca simplifie pas mal mais j'ai une nouvelle erreur maintenant.

Mes animations n'étaient au début que Drawable. Maintenant il faut que je les places aussi Transformable pour pouvoir changer leur positions/centre/ratio/rotation/... facilement.
Mais lorsque j'essaye de faire l'héritage j'obtiens une erreur :

TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict

J'ai alors vu dans une doc de pysfml2 qu'il pouvait y avoir sf.TransformableDrawable mais elle n'est pas dans mon paquet.

Je peux contourner le problème en appliquant la transformation manuellement à chacun des sprites de l'animation mais je trouve ça moche.