faire et défaire …

autre bonne nouvelle: les animations marchent! enfin, quand je dis “marchent”, je devrais plutôt dire “rampent”, puisque pour l’instant, seul le “petit ver jaune” de la forêt a été animé.
Je suis pas mal fier de mon coup, je dois dire. J’ai gardé un code tout à fait générique, qui est paramétrisé par un petit script de commandes. Petite astuce, les déplacements du ver sont intégrés dans la séquence d’animation elle-même, ce qui permet d’avoir un contrôle plus fin du déplacement (pour vraiment donner l’impression que le ver rampe, et pas qu’il glisse sur le sol pendant qu’il se tortille, comme on le voit si souvent dans les jeux amateurs).

En revanche, si je commence à être assez rôdé sur les std::vector::iterator, je suis encore un peu perplexe sur les destructeurs virtuels. L’environnement d’exécution du “petit script” en question doit être “renettoyé” chaque fois que l’on veut relancer le script, et pour l’instant, ça se traduit encore trop souvent par un écran rouge de la mort. J’aime bien la méditation, mais toutes les 5 minutes, ça devient lassant. (quicklink: l’assembleur ARM par TONC: http://www.coranac.com/tonc/text/asm.htm)

D’un autre côté, j’ai un peu relooké mon script qui traduit une image (comme celle ci-dessus) en un tas de tiles et les données pour la map, de sorte qu’on puisse lui indiquer quelle couleur doit être considérée comme “transparente”, et il s’arrange tout seul pour que les tiles entièrement de cette couleur soient considérés par la toute nouvelle routine de “testpoints” comme étant “EMPTY”, tout le reste étant de type “BLOCK”…

edit-PS: la première version du level editor (sans sauvegarde) n’arrivera qu’en avril de l’année à venir. Là, on est donc toujours dans une “composition” de niveaux à coup de Gimp suivi d’une conversion avec détection des tiles redondants par un script fait-maison.