Discussion :

[esodpi]

Bonjour,
J'affiche un Map à l'écran (fichier .tmx) et je fait bouger un personnage.

Le problème: J'ai besoin de ne pas à avoir à recoller (blit) la MAP après chaque mouvement du personnage.

Car le personnage bouge à l'aide de la souris donc long parcours (+2 images d'animation actualisé 4x pour une distance de 32px).
Donc pour un parcours de 10 cases je devrais actualisé plus de 40 fois la Map

Il me semble que la solution à ce problème passe par le fait d'ajouter un couche au fichier .tmx réservé au collage du personnage (Pour effacer l'écran sans effacer les premières couche de collage(décors/map)), mais je vois pas comment faire...

[BufferBob]

salut,

ça ne me choque pas particulièrement ce que tu expliques, et à la fois peut-être que je me représente mal le problème, le plus simple serait sans doute de mettre tout ou partie du code, une vidéo ou autre peu importe, pour qu'on puisse se rendre compte un peu plus précisément

[esodpi]

Alors le problème est que le code fait plus de 600 lignes (Qui est divisé en quelque partie, Mais toute dépendante l'une de l'autre ...)
et qui n'est pas assez organisé ni documenté pour qu'une personne puissent le comprendre sans faire brûler la scrollette de sa souris ,
et je n'ai jamais fais d'enregistrement vidéo

Ceci dis je me suis renseigné et apparemment la solution à mon problème serais d'utiliser la méthode "Dirty rect animation",
donc je vais essayer ça sinon en dernier recours j’essayerais de réduire le code à l'essentiel.


Merci

[LittleWhite]

Bonjour,

Je verrai deux techniques :

• coller tous les sprites de la carte dans une surface dédiée pour ensuite l'afficher d'un coup dès qu'il y en a besoin ;
• utiliser un système d'invalidation des sprites et redessiner que les sprites invalidés (ce qui correspond au dirty rect animation).

La première technique, je ne pense pas que cela sera avantageux car tous les pixels de l'écran seront redessinés, comme avant.
La seconde technique ne redessine que ce qui est nécessaire et ça, c'est cool

[BufferBob]

La seconde technique ne redessine que ce qui est nécessaire et ça, c'est cool

d'ac je connaissais pas, mais je ne peux m'empêcher de me demander, c'est une technique d'actualité/encore utilisée aujourd'hui ? parceque bliter 2 ou 3 fois l'écran même dans sa totalité ne me parait pas insurmontable en 2015bientôt 2016, le dirty rect en revanche a pas l'air si simple à implémenter

Edit: un lien peut-être intéressant, la conclusion notamment : http://subr3v.blogspot.fr/2014/08/di...rformance.html

[LittleWhite]

Pour pygame, je pense que cela est d'actualité. pygame repose sur la SDL 1.2 et celle-ci effectue complètement son rendu par le CPU. Du coup, on utilise pas la puissance de la carte graphique, mais en plus, cela peine si on doit dessiner l'intégralité de l'écran : http://alexandre-laurent.developpez....ces-de-la-SDL/
Donc, pour pygame, je pense que ce soit une bonne chose (et je pensais que c'était bien amené par la bibliothèque, grâce au système de groupes et je ne sais plus quoi d'autre). Après, bien sur, il faut que le jeu s'y prête : ce qui est le cas pour un Zelda like ou un jeu avec une carte en grille, dans le fond. .