Gaming Maze

Les points de développement dont parle cet article ont eu lieu début novembre 2010.

Le personnage était enfin sur une vraie carte.

Les problèmes pouvaient commencer…

Tout allait bien tant que le personnage restait immobile. Mais dès lors que je tentais de le faire bouger d’une case à une autre, son mouvement était terriblement saccadé.

Si la portée de l’éclairage affiché était plus faible, le mouvement redevenait relativement fluide. Mais dès 10 cases de portée, les ralentissements qui se produisaient n’étaient pas tolérables.

Le mouvement du personnage n’est pas fluide du tout

Le problème pouvait avoir deux sources différentes :

- la fonction de calcul de l’éclairage. Si celle-ci met trop de temps à s’exécuter pour un changement d’hexagone, normal qu’on constate un lag. Le programme réfléchit pour calculer tous les hexagones éclairés, et pendant ce temps-là, il ne fait pas bouger le personnage.

- le rendu de l’éclairage. Autrement dit, sur le screen, le fait de faire passer certains hexagones en jaune, certains en jaune clair, et faire repasser les hexagones non éclairés en gris. Si le programme prend trop de temps à produire ce rendu, pareil, pendant ce temps-là, il ne fait pas bouger le personnage.

rendu de l’éclairage : éclairé, pas éclairé, peu éclairé

Pour déterminer la source du problème, j’ai désactivé le rendu de l’éclairage. Ce qui fait que quand le personnage bougeait, à chaque nouvel hexagone qu’il atteignait l’éclairage depuis cet hexagone était calculé par la fonction, mais toutes les cellules restaient grises.

Et le mouvement du personnage était redevenu fluide, même avec une portée d’éclairage élevée (donc plus d’hexagones à considérer par la fonction, donc un temps de calcul plus long).

Bref, le rendu des hexagones éclairés était donc entièrement à blâmer pour les ralentissements.

Heureusement, une solution très simple était à portée de main. En effet, jusqu’alors, le rendu de l’éclairage n’avait pas du tout été optimisé, et à chaque nouveau mouvement du personnage, le rendu de tous les hexagones dans la portée de l’éclairage était recalculé et ré-appliqué. Ce qui faisait beaucoup de calculs inutiles, car d’un hexagone à hexagone adjacent, l’éclairage ne varie pas beaucoup : pratiquement toutes les cellules qui étaient éclairées le restent, il n’y a pas besoin de les éteindre puis les rallumer.

Une fois l’optimisation effectuée (le rendu n’est plus calculé que pour les cellules qui changent d’état) les mouvements sont redevenus fluides.

***

Je pouvais donc passer à la mise en place du scrolling : des boutons de chaque côté de la carte qui permettent de la faire défiler dans toutes les directions.

Mais, là, rebelote !

Le scrolling est saccadé…

Voilà un problème épineux. D’entrée de jeu, je n’avais aucune idée de ce qui pouvait causer de tels ralentissements.

Après pas mal de tests, je trouve le responsable, ou plutôt les responsables : les calques de Flash.

En effet, je me reposais pas mal dessus. L’hexagone de base comportait plusieurs calques, un pour l’éclairage notamment. Il comprenait une forme identique à l’hexagone qui était jaune et légèrement transparente. Ainsi, lorsqu’un hexagone était éclairé, le programme affichait ce calque, lorsque l’hexagone ne l’était pas, il le cachait.

J’ai fait une version de l’hexagone qui n’utilise qu’un seul calque et j’ai modifié le code pour produire le rendu de l’éclairage sans utiliser les calques. Et bingo, le scrolling était beaucoup plus fluide.

Le rendu obtenu était un peu différent de la version précédente, mais juste parce que je n’avais pas cherché à obtenir exactement la même chose. Tout cela n’était que temporaire, de toute façon.

Un rendu différent (avec un bouton de scrolling à droite)

Un peu plus tard, en me renseignant, j’ai entendu parler de la propriété « cacheAsBitmap ». Cette propriété permet en gros de mettre en cache et afficher sous forme bitmap un contenu vectoriel, ce qui fait que lorsqu’on zoome dessus, on obtient un rendu pixellisé et non plus lisse, mais cela fait aussi (et surtout) que lorsque le programme affiche le contenu, il n’a plus à calculer tout le rendu vectoriel des différentes formes : il affiche simplement le bitmap qu’il a en mémoire.

Une fois « cacheAsBitmap » appliquée à la carte, le scrolling atteint une fluidité qu’on aurait à peine crue possible…

A ce stade-là, j’utilisais encore principalement l’environnement de développement Flash pour structurer mes projets, car c’est le plus simple pour débuter, notamment parce que la majeure partie des livres et tutoriaux sur Flash l’utilisent. Mais je me servais déjà du logiciel FlashDevelop pour éditer mes fichiers Actionscript, l’interface de ce dernier étant bien plus pratique pour écrire du code. La suite du développement m’a amenée à utiliser beaucoup plus FlashDevelop, comme je vous en parlerai dans les prochains articles.

Index des notes sur notre tactical