Discussion :

[Julien Bodin]

Bonjour à tous !

Je travaille toujours sur mon éditeur de tuiles et maintenant que je peux construire le décor j'aimerais pouvoir poser des tuiles "animées".
Au départ je voulais que lorsque l'utilisateur clique sur Ajouter une tuile une boite de dialogue s'affiche dans lequel il pourrait charger plusieurs images et définir un temps entre chacune des images.

Ce qui rendrait possible par exemple que Tuile1 ait 100ms entre chacune de ses images et Tuile2 75ms.
Ca peut être pas mal de pouvoir régler ça avec un curseur et de voir l'animation s'accélérer ou se ralentir, en tous cas ça me semble plus souple d'utilisation pour l'utilisateur qui n'aura pas forcément besoin de redessiner ses tuiles pour coller à un timing fixé.

C'est peut-être un peu plus compliqué à mettre en place mais pas tant que ça j'imagine (un thread par tuile qui se charge de changer l'image à afficher puis un thread qui se charge de repeindre la surface d'affichage de mon application).
J'ai surtout peur de la consommation de ressource étant donné que le jeu final devra tourner sur un OS Mobile (Android).

Qu'en pensez-vous ?

[luckyvae]

ça ferait surtout beaucoup de thread qui tournent pour n'afficher que des tuiles...

Il y a un autre moyen:
retenir le temps nécéssaire entre chaque image et à partir du temps courant, en déduire la tuile devant être affichée...
si par exemple tu as un changement de tuile toutes les 75 ms avec 4 tuiles différentes et que depuis le début X ms se sont écoulés alors
numéro de la tuile à afficher = (X%75)%4

je n'ai jamais testé cette solution, je viens de le mettre comme ça, donc ça peut ne pas être juste, mais c'est l'idée...

[Julien Bodin]

ça ferait surtout beaucoup de thread qui tournent pour n'afficher que des tuiles...

Il y a un autre moyen:
retenir le temps nécéssaire entre chaque image et à partir du temps courant, en déduire la tuile devant être affichée...
si par exemple tu as un changement de tuile toutes les 75 ms avec 4 tuiles différentes et que depuis le début X ms se sont écoulés alors
numéro de la tuile à afficher = (X%75)%4

je n'ai jamais testé cette solution, je viens de le mettre comme ça, donc ça peut ne pas être juste, mais c'est l'idée...

Très bonne remarque ! Ca va me faire gagner pas mal de temps Et éviter plein de soucis avec les threads finalement

[nouknouk]

ça ferait surtout beaucoup de thread qui tournent pour n'afficher que des tuiles...

+100

retenir le temps nécessaire entre chaque image et à partir du temps courant, en déduire la tuile devant être affichée...

Je vois un souci avec cette solution: elle suppose qu'à chaque image affichée, tu redessine l'ensemble de la scène (les tuiles qui ont bougé comme celles qui n'ont pas bougé).

J'ai cru comprendre que tu programmais pour Android, que je ne connais pas personnellement, mais j'imagine que le principe est identique à pas mal d'autres API 2D : en règle générale on ne redessine uniquement ce qui a changé entre deux images.

C'est le principe des 'dirty rectangles' (à savoir calculer les portions de l'écran à redessiner parce que quelque chose a changé entre l'image précédente et la nouvelle). Un exemple conret: cet exemple du framework pulpcore : une fois l'applet chargée, tape "Control + D" et tu verras en temps réel les rectangles verts (les fameux 'dirty rectangles') qui représentent les seules portions de l'image redessinée.
Tu remarqueras notamment que le bonhomme est redessiné à chaque image car il bouge tout le temps, tandis que les étoiles (fixes, mais animées) ne le sont que quand l'animation engendre une nouvelle image.

De plus, il faut toujours garder à l'idée que les performances de l'affichage doivent être à peu près constantes quelle que soit la taille du terrain (ie. le nombre de tuiles totales de ton monde).

D'où les idées suivantes:

1- lorsque la vue change (on fait un scrolling)

* 1.1 on recalcule la liste (listTile) de l'ensemble des tuiles qui seront affichées. Ainsi, on restreint les calculs à l'équivalent d'un screen de tuiles, quel que soit la taille de ton terrain.

* 1.2 à partir de listTile, on construit la liste de toutes les tuiles animées animTileList (puisque celles inanimées, on les affichera une seule fois et ça suffira).

* 1.3 pour tuile d'animTileList , on calcule la date du prochain changement d'image de l'animation et on le stocke dans une liste (changeTilePic) avec une référence vers la tuile concernée, le tout ordonné par date croissante.


2- à chaque itération de la boucle d'affichage.

* 2.1 on parcourt la liste changeTilePic ; pour chaque élément date dans le passé (ie. sur le prochain screen, la tuile doit changer), on redessine la tuile avec la nouvelle image ; on supprime cette entrée pour cette tuile dans changeTilePic et on en ajoute une nouvelle (à la fin de la liste) correspondant à la Date de l'image suivante. Dès que l'entrée itérée de changeTilePic est dans le futur, on arrête d'itérer sur cette liste.
Tu noteras d'ailleurs qu'on n'itère -in fine- que sur la première entrée de changeTilePic : si elle est dans le futur, on l'enlève (et on en rajoute une en fin de liste) et la prochaine itération se fera sur la 'nouvelle' première tuile de la liste ; si elle est dans le passé, on arrête d'itérer.

* 2.2 même principe pour les sprites qui vont se déplacer au dessus de tes tuiles: on calcule les tuiles recouvertes par le sprite avant déplacement ; on les redessine ; on déplace le sprite et on l'affiche. Ainsi, on ne redessine que la partie du screen qui change, pas toute la scène.

[Julien Bodin]

D'où les idées suivantes: [...]

Merci pour ces indications ! J'ai de quoi faire de belles optimisations
Même si rien n'est vraiment codé encore

[nouknouk]

Première chose: j'ai édité entre temps mon post ci-dessus pour ajouter le paragraphe sur les 'dirty rectangles', avec un exemple.

Deuxième chose: mon explication ci-dessus ne vaut que pour une API de dessin en 2D ; quand on utilise une librairie 3D, genre OpenGL (ES), là chaque image est entièrement redessinée.