Phantom Hourglass

Je l'ai attendu pendant pas mal de temps... J'ai résisté tout le temps de la finalisation de thèse. Maintenant je l'ai: ma fée m'a offert "Phantom Hourglass" pour ma Noël ^_^

Persos en 3D et contrôle au stylet, je dois dire que je n'étais qu'à moitié convaincu que ça allait me plaire (je n'ai jamais été un grand fan des jeux 3D et le côté "low polygons" de "Ocarina of Time" et "Majora's Mask" était très décevant à mon sens).

La première bonne nouvelle, c'est que dans les phases de jeu, la 3D passe plutôt bien (grâce à la vue d'en haut qui conserve le gameplay d'un zelda classique, notamment). Du point de vue des personnages, par contre, je trouve qu'on a perdu de la "magie" par rapport à "Minish Cap" sur GBA. Ils ont un peu tous l'air de porter des masques en toile de jute peinturées à la place du visage, rebondissent en parlant d'une manière assez peu naturelle. Bref, on est loin des minish mimi-tout-plein en pixel art du volet précédent. snif.

Le stylet, par contre, est redoutable, même si j'ai tendance à vouloir utiliser la croix pour déplacer link à certains moments (dans les combats, notamment, c'est difficile d'esquiver un grand nombre d'ennemis). On quitte le mode 'contrôle absolu' des jeux précédents pour quelque-chose qui ressemble d'avantage à un "command&conquer". Si certains mouvements (roulade, épée tournoyante) sont plus difficiles à exécuter que dans les bons-vieux-zelda-en-pixels (je l'ai dit), le boomerang dont on peut tracer la trajectoire compense largement. C'est d'ailleurs une de mes techniques de combat préférée: assomer la plus grande partie des grogneurs à coup de boomerang pour aller me concentrer sur un monstre pendant que les autres comptent les ptits zoizos.

Reste le très controversé "temple du roi des mers", ou "temple du sablier fantôme" ou "temple maudit". Appelez-le comme vous voudrez. Avec ces gardiens-spectres indestructibles, il introduit une dimension "infiltration" assez nouvelle dans le genre. Je le trouve stressant. Très stressant. Mais avec une bonne mémoire et des notes correctes prises sur la carte, on ne s'en sort finalement pas si mal. Oui, on doit le revisiter plusieurs fois, mais à chaque visite, on dispose de nouveaux "outils" (bombes, pelle) qui permettent au joueur attentif de prendre de fameux raccourcis et de grapiller des secondes supplémentaires dans les jarres dorées. Ajoutez à celà des minutes gratuites retrouvées au fond des mers, et je suis arrivé au "blason du soleil" avec 8'42" restantes (contre moins de 2 minutes de temps restant la dernière fois que j'ai du le faire.

Bon, évidemment, ce serait trop beau si ça avait été un rien utile. Bin non. Je me suis précipité jusque là pour rien. La "clé solaire", c'est pour un autre temple, ailleurs ...

Les dongeons sont chouettes (enfin, corsés, quoi, mais on s'en sort sans la soluce à l'exception de deux ou trois énigmes dont les indices sont donnés de manière foireuse). Les boss bien dosés (quoi qu'aucun d'eux ne m'aient encore tué :P) ... Je suis déjà au navire fantôme en seulement 3 jours ... C'est grave, docteur ?

edit: ma fée vient ingénument de tirer la cartouche du jeu que j'avais laissé en veille avant d'essayer de ramener la quatrième soeur au début du bateau fantôme pour faire ses exercices d'entrainement cérébral. Comme vous pouvez le voir, elle ne recule vraiment devant aucun sacrifice pour rallonger la durée de vie de son cadeau ^^"

edit+: c'est bien, le stylet, mais dans les combats contre les boss, ça a un inconvénient majeur: ça glisse des doigts. Croyez-le si vous le voulez, mais je me suis retrouvé crétin comme un lapin pendant le combat contre le crabe invisible qu'il faut viser entre les yeux à avoir mon stylet qui me "zippe" entre les doigts! Ledit crabe en profite naturellement pour me choper et le jeu dit "frotte l'écran pour te libérer". Ah ouaiche.
Je m'en suis sorti quand-même, mais de justesse. 'Suis pas sûr d'être 100% prêt pour Twilight Princess sur la Wii, moi ^^"

edit++: oh, j'aurais peut-être dû préciser que mon Zelda préféré (toutes catégories) était "Link's Awakening" sur le tout vieux GameBoy. Vous comprendrez sans doute mieux ma difficulté à accrocher à OT et MM, du coup :P

edit+++: vous êtes coincés mais vous n'avez pas envie de consulter la soluce du jeu ? repassez faire un bonjour à la voyante de l'île du feu. C'est gratuit et elle aura peut-être même un petit cadeau pour vous ;)

spr2html ^_^

Il parait que j'ai tendance à utiliser HTML pour tout et n'importe quoi ... j'ai bien peur d'avoir remis ça ... J'avais bien un petit script capable de transformer une image (de préférence un niveau de jeu) en un 'SpriteSet' (que j'utilisais pour les tests de scrolling), mais jusqu'ici je n'avais rien d'équivalent pour le sens "retour".

Et comme j'ai un peu la flemme d'écrire des pixels sur une image .png, je me suis plutôt tourner sur une jolie petite table HTML. Avouez que le résultat est plutôt réussi, non ? bon, évidemment pour l'instant on ne voit encore que les "tiles" un par un, tels qu'ils sont dans la mémoire vidéo, mais encore un peu de chipotage, et je pourrai les voir par "bloc" de 16x16 ...

De quoi simplifier les procédures de conversion de données que je vais devoir faire... Parce que là, sans un éditeur de map, je n'irai pas beaucoup plus loin. Animer les pommes qui n'utilisent pas des tiles consécutives. bof.

So far, the tiles you edited with SEDS could only be opened with SEDS (or shown on your DS screen through the 'runme' companion program). That was true until yesterday. Here comes the "spr2html" converter tool that can turn those "opaque" .spr files into a bunch of HTML tables that show palettes and tilesets contained in the spriteset. So far, it is mostly a debugging tool for the other manipulation scripts (merging sprite sheets, converting colors, etc) that prooved to be more efficient than beaming files to the DS and back, but it should be quite trivial to upgrade into a full-featured "exporter" that would produce .png pictures straight out of my .spr files...

edit: et je me rends compte de la raison des palettes "toutes mélangées" que j'ai obtenues dans mes "livres de sprites" qui rassemblent plusieurs planches séparées: je comptais les couleurs 1,10,11,...,19,2,20,21, ... 29,3 ... à chaque étape, alors forcément, quand on répête ça, on finit par un jeu de couleurs tellement mélangé qu'on est prêt pour une petite belote :P

oh, for those who wonders, i've used the "bgcolor" attribute of "td" tags and and solely filled my table cells with to ensure they'd have the proper size. That doesn't seem to please all browsers around, but as long as one of them (konqueror, but not firefox) renders it fine, i'm happy.

Plagiat ?

"C'est quoi, ce plagiat de Worms" demandait Bodman il y a 2 ou 3 posts... Euh, j'avoue, j'ai toujours été un fan du jeu, et quand j'ai du "relifter" mon "yelloworm" pour la forêt de Bilou et qu'une silouhette un peu "wormesque" est sortie sur ma petite grille 16x16 de SEDS, j'ai trouvé qu'elle donnait plutôt bien.

Du coup, les illustrations sont encore un peu plus "worm-inspirées". Mais j'ai un affreux doute. Mon ver jaune pixelisé est il assez "original", ou donne-t-il l'impression d'un repompage honteux du jeu de Team 17 ? C'est un peu le défaut des blogs, à mon avis. Je lis régulièrement les messages de bodman et j'imagine qu'il lit mon blog aussi, mais je n'ai aucun moyen de l'inviter à une petite discussion sur ce qu'il pense réellement de mon ver, au-delà de ce qu'il a déjà dit. Personne ne laisse d'adresse mail nulle-part vu qu'on a tous peur de recevoir (encore plus) de spam ... Bin moi, mon e-mail c'est pype_1999.geo@yahoo.com. Et je ne vois pas comment je pourrais avoir encore plus de spam là que je n'en reçois déjà. Donc, si bodman ou un autre veut prendre contact pour une petite discussion sur ICQ (#98176626) ou msn (je vous enverrai mon adresse par retour de hibou), you're welcome ;)

edit: après une (chouette) petite discussion sur ICQ, j'ai fini par apprendre que bodman avait visiblement fort idéalisé les petits vers de la première version de Worms, qui sont beaucoup plus proche des lemmings, et avec des yeux biens plus proéminents. Non, à la réflection, je pense avoir réussi un bon croisement entre le Worms Armageddon et le "Poison Slug" de Commander Keen. Un double clin d'oeil, donc.

oh, et la démo du Worms original de 1995 est un peu lente dans dosbox, mais tout à fait jouable ^_^

Des pentes et des testpoints ...

Je relisais ce document sur la réalisation du jeu M.C. Kids, et j'ai enfin compris pourquoi ils avaient eu tant de mal à prendre en compte les pentes dans la "gestion des collisions". (J'ai un peu du mal à parler de détection de collision entre sprite et décor, vu que j'ai utilisé ce terme pour les collisions sprite-sprite pendant des années ;)

Bref. L'idée globale des testpoints, c'est s'assurer que le testpoint situé sous le personnage soit toujours à la frontière entre le "ciel" et le "sol". Ultra-simple sur des horizontales, un peu plus subtil sur une pente (mais grosso-modo il suffit d'ajuster le déplacement vertical en fonction du déplacement horizontal). Le hic, c'est de passer d'une surface horizontale à une pente. LE hic, c'est que la pente commence devant notre personnage alors que le point-test que l'on doit garder sur cette pente est sous le personnage (ici, yelloworm). En clair, notre worm va soit s'arrêter avant la pente (s'il la considère comme un mur), soit rentrer dans le premier tile puis s'arrêter au premier bloc de "mur" complet.

Dans M.C. Kids (et selon les dires de l'auteur, dans SMB3 également), ils résolvent le problème en introduisant un nouveau type de tiles: le "bas de colline", qui est placé dans le sol, dans le prolongement de la pente à amorcer. Ca marche, bien sûr, mais personnellement, je trouve ça un peu "bricolage". Un autre point qu'ils mettent en avant, c'est l'importance de garder un nombre de "test de map" fixe et le plus réduit possible -- de préférence un tile par testpoint.

Mais nous avons de toutes façon un testpoint devant notre personnage: celui qui sert à déterminer si oui ou non on arrive dans un mur. Et il est important de s'assurer qu'il soit suffisamment bas pour qu'il stoppe Bilou (et le yelloworm) même si le mur est très bas.

Du coup, on peut en profiter pour détecter le début d'une pente quand on arrive un tile avant. Il nous reste alors à ajuster la vitesse verticale de manière à ce que, un tile plus loin, on soit monté d'un pixel. On sera alors effectivement "sur" la pente. Bingo.

Il faudra évidemment s'arranger pour que l'angle entre les deux testpoints soit suffisant par rapport à l'angle de la pente la plus forte dans le jeu, mais ça, ça ne devrait pas nous poser de problème particulier.

Voilà. C'était ma cogitation du dimanche un peu en retard ... j'espère que c'était suivable ^_^

Tile Racer

une fois n'est pas coutume, c'est d'un jeu PC que je voudrais mettre en avant. "Tile Racer", une reprise du concept de "Stunts 4D Driving" par trois étudiants autrichiens, qui -- à mon avis -- vaudra le coup d'être testé.
Comme dans S4DD, vous pourrez construire vos propres circuits de dingues (mêlant tonneaux, loopings, rampes, tremplins, etc) à l'aide d'un éditeur basé sur le modêle des "tiles" (mosaïques, en gros) avant d'y faire une petite course contre la montre.

Patience: l'adversaire IA est en cours :P

demi-tour, marche!

Et voilà. Le mécanisme des "testpoints" est ajouté. Avant de recommencer chaque étape d'animation, mon petit ver s'assure qu'il ne rentre pas dans un mur et qu'il ne tombe pas. Je ne suis pas certain que ça conviendra pour tout le monde (Bilou, en particulier).

Il faudra aussi que j'automatise le demi-tour (pour l'instant, le ver s'arrête au bord, et je lui fais faire demi-tour "à la main" en programmant la deuxième animation.

edit: yes! le petit ver est maintenant entièrement autonome et toujours avec un code 100% générique. Une petite machine d'état avec des animations de "pause" entre les allées et venues, et ça y est. Et je peux en mettre autant que je veux! il suffit de rajouter une ligne dans test.cmd ;) Etapes suivantes:

• animer les pommes
• désactiver/réactiver les OAM quand ils sortent de l'écran
• passer *réellement* à deux plans pour l'affichage du décor
• scrolling parallaxe
• (post-posé: animation composite pour Bilou).

J'ai aussi commencé un nouveau graphisme pour Bilou: là, je le trouve vraiment trop petit par rapport au "reste du monde".

Got the testpoints support added. Before playing the 'walk' animation again, the woodworm will check it wouldn't enter a wall and wouldn't fall down. It might not work for every entity (clearly not for Bilou), but it does the job here. Adding a turn-back ... there we are. Fully autonomous entity patrolling on a platform with completely generic code. First state machine ever, and I can replicate them here and there by just adding one line in test.cmd file.

iWorld has non-virtual desctructor

Okay. Ca y est. Après avoir donné un destructeur virtuel à la classe iWorld (:P), et surtout une fonction reset() à la classe GameObject pour s'assurer que les nouveaux sprites ne vont pas essayer de "vivre" dans l'ancien monde (détruit) après reconstruction du nouveau monde, je peux recharger mon script de niveau autant de fois que je le souhaite dans runme.

Oh, il y a eu d'autres chipotages, bien sûr. Les sprites et quelques autres éléments sont enregistrés directement auprès du GuiEngine, pour les animations notamment, et il est assez malvenu de supprimer l'un deux sans l'avoir "désenregistré" sous peine de voir le moteur du jeu essayer d'animer les morts (sic).

Oui, je sais, c'est assez macabre. Mais que voulez-vous: la Faucheuse (traduisez: le Garbage Collector) n'est pas de mise en C++ et quand un objet meurt, il est pour ainsi dire obliger de s'enterrer lui-même.

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.

Et les sprites ?

Je suis confronté au même problème que Syra. Scroller, c'est bien, mais les sprites (Bilou et compagnie) ignorent royalement ce qui se passe sur la couche de fond, et qu'on se retrouve donc avec les monstres qui restent "scotchés" sur l'écran alors que le niveau du jeu défile par derrière.

Rien de bien méchant à arranger, mais ça demande quand-même un peu de (ré)organisation du code, ce qui me prend systématiquement une plombe. Enfin, dans l'immédiat, ça ne marche pas trop mal, excepté un petit "glitch" désagréable (le fond est déplacé trop tôt par rapport aux sprites, ce qui leur donne de s'enfoncer dans le sol quand on scrolle vers le haut, par exemple).

Ce midi, j'attaque les animations !

Yes! Ca scrolle!

C'a été un drôle de combat, reprennant les bonnes vieilles habitudes du cours Algo I (invariants, etc) pour parvenir à faire scroller le niveau de Sonic sur ma DS. Faire un scrolling vertical, c'est simple. Le scrolling horizontal m'a déjà donné plus de fil à retordre, mais pour s'assurer qu'ils n'essaient pas de s'assassiner dans les coins, j'aime autant vous dire que ça ne va pas sans mal.

J'ai laissé tomber les transfers DMA pour la plus grande partie du code. L'idée maîtresse ici était une "fenêtre de validité" qui indique quelle portion de la map est effectivement présente dans la mémoire vidéo, et à partir de quelle position. L'ennui, c'est que pendant tout un temps, le scrolling "vertical" modifiait des zones que le scrolling horizontal tenait pour acquises. Bref, on se retrouvait avec de gros blocs de terre au milieu du ciel, de l'eau dans le sol, des hybrides guèpes-singes, etc.

mais ça y est. Ca marche. Pour les curieux, le code est sur le CVS. Et au passage, j'en ai profité pour commencer un petit interpréteur de scripts pour ce genre de tests (histoire de pouvoir réutiliser un fichier .spr transféré préalablement). L'ennui, avec ce genre de méthode, c'est qu'il vous faudrait 5 minutes pour mettre en place le test à partir de runme.nds ... D'où la vidéo ;)

Pas de musique sur la vidéo, donc si vous voulez vous mettre dans l'ambiance, jetez une oreille à "Oil Ocean (WT-40 mix)" qui m'a accompagné lors de tous ces tests ^_^

edit 2024: Le CVS, c'est fini, et le travail sur le scrolling arrive d'un bloc dans le repository mercurial. Entre les deux, il y a eu un SVN où on voit le travail évoluer jusqu'à l'étape ça marche (4 décembre).