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).

Good news: animations are working: we can now see the yellow woodworm crawling through the level. I love how it keeps the code generic script commands. Another nice element: worm motion is integrated into the animation sequence, allowing for tighter control on how motion and frames fit together. It really feels like the worm is crawling, not sliding+giggling as I see too often in other works.

The down side is that I face too many red-death-screens while developing that. I guess this is my understanding of C++ virtual destructors that is still too far from sufficient. Since the whole environment in which "scripts" are evaluated must be cleaned up and rebuilt at every new attempt, I'm calling them a lot. And while I can enjoy some guru meditation, too much gets boring.

En revanche, si je commence à être assez rôdé sur les std::vector<GameObject*>::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"...

I'm still doing this with a picture-to-map script, with the 'level' being built with the Gimp, but now my tool producing tiles and map data out of the picture can be told what color is to be seen through and tiles completely made of that color will be considered empty by testpoints routine, while the rest of the map is said to be of type "BLOCK". Basis of sprites-to-world collision. A milestone is reached. (first Level Editor build - with no saving - will only come next April. NdlR)

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.