OAM priority issues

I'm about to introduce significant complexity in the game engine for the purpose of displaying some compound animations properly. I've took the time to think about it (while drilling staircase for a kid-safety-barrier, if you ask :P) and figured out how to sort all the needed details. I just missed one point: this is absolutely not the only place where I need OAM depth-sorting.

Remember of Apple Assault's frenzy, and how you could end up not seeing that appleman that runs towards you because it's actually sneaking behind a row of stunned applemen ? That's never been fixed to date because I had no way to instruct the game engine that "those stunned applemen should be moved to the background".

Then I remembered of that "talk" by Rafael Baptista about resource management on the GBA. Before he entered the core meat of his talk, he suggested that copying OAM entries (you can think of them as sprite descriptors) could be the right time to follow a Z-order linked list and keep the "hardware" OAM entries and their "shadow" counterpart. Nice move, although I still wonder how he manages the scaling/rotation matrices along the way...

I used to have a large, one-chunk DMA transfer of all the sprites & rotation information. I would have to split that in 3-u16 slices. That sounds like I'll have to pay sverx's report on memory copies performance benchmark a second - and more careful - read... and possibly opt for an intermediate - sorted, but in-cache - version out of the vblank period and then DMA that into VRAM when the vblank is hit.

A final consideration: there is little chance that I need a fine-grained Z-sorting. low/normal/high priority should be enough in 99% of the cases, and the remaining case could likely be "sorted" out at GOB instanciation by internally sorting the OAMs the GOB received.

edit: I asked myself the right question: 'is that move out of DMA sync'ing gonna cost me framerate or not ?'. From that point on, I hacked a modified version of my game engine, that uses CPU-driven copy with merging of OAM and rotations into one single table (as the DS hardware expects) and started Apple Assault with aggressivity setting turned at max (so many apples that you'll experience "ghost" berry bats and shots). Good news: it still works flawlessly (that is, I can't observe any slowdown). Next: the depth-re-ordering...

edit++: just applied silly reverse-priority and order-enforcement-at-sync() in an AppleAssault check: it proves the concept: now Bilou can sneak behind stunned applemen. Useless, but you can't deny it's no longer the default z-order that is applied.

edit+++: checked that a (Simple)Gob set on zlist[0] appears in front of (Compound)Gobs set on zlist[1]... now I've got to figure out how to use that best to implement the pullmask for my "roll jump" animation ...

petit computer

Mais, mais ... du neuf sur le DSi Ware ? Heureusement que Digital Tools est là pour me tenir informer. Voilà qui va fameusement plaire à Pierrick : un BASIC sur la DSi: Petit Computer. Avec support des sprites, décors et même de quoi faire des p'tites mélodies. On va même pouvoir s'échanger nos programmes sous la forme de QR-codes (imprimés sur des étiquettes collées sur les floppies des années '80, bien sûr :) Bien vu, SmileBoom ... ça va faire mal ^_^

Voilà qui va faire une sérieuse concurrence à mes p'tits outils homebrew ... mais c'est une joie immense de voir le "homebrew coding" de ma jeunesse enfin compris et approuvé par Big N ... bon, y'a probablement pas de SYS 16384, mais qu'à celà ne tienne ...

Creating and sharing your own BASIC tools and games on the DSi, with only Nintendo-approved software... does that sounds impossible ? check it out for yourself

REALITY CHECK: Amère déception après la mise à jour système: le logiciel n'est pas encore disponible en Europe. Et je suis optimiste sur le "encore"... Il a fallu près d'un an pour que 'Inchworm Animation' traverse l'Atlantique, et on attend toujours Cave Story. La traduction de tous ces textes prend un temps considérable, hein ... M'enfin, quoi, c'est à ce point la fin du monde de faire une catégorie "dans ma langue préférée" ou "dans n'importe quelle langue" en laissant à l'acheteur la possibilité "d'upgrader" dans sa langue une fois le jeu enfin traduit.

Hey, GameBridge and SmileBoom, if you're reading this don't stop after the US: Europe wants Petit Computer! We are the land of the micro-computers! We've been playing on C64 even in the nineties and have dropped our Amigas only when the PlayStation decided the market for micro-computer games should no longer exist. I won't care if translation isn't complete: most of us can understand English anyway, so please, go to your Nintendo representative and ask them how translations could be provided as a downloadable upgrade. Stop reading and go releasing ... just ... please.

pullmask

Je vous disais que l'animation de Bilou avait été fortement inspirée par Fury of the Furries ... Ça m'a donc semblé normal d'utiliser le "roulé-boulé-en-l'air" comme cas de test des "animations de transitions". Entre "je tombe" et "j'ai rebondi", par exemple.
Après avoir dessiné quelques sprites de plus pour Bilou lui-même, je me suis retrouvé tout bête dans AnimEDS: pas moyen d'avoir les pieds de Bilou qui passent devant puis derrière son corps, vu que l'ordre d'affichage reste fixe.

Bilou has Sonic and Fury-of-the-Furries influences, and one of them is rolling in the air. I wanted to use that as a test for transanims, and I started pixel'ing more rolling frame for Bilou's body. But when I opened AnimEDS to convert it into a full-blown animation, I just went ^^" : it's notwasn't built for animations where the relative order of limbs change over time. In short, the order you add limbs in the 'skeletton' also define which limbs obscures which other one. To do a roll, Bilou's feet need to be shown in front of his body in some frame, and behind his body on other frames. That just was impossible before AnimEDS revision 999 which features a "pull" button that let some limbs belong to a "second pass" rendering.

Bon, maintenant, il faut que je trouve le moyen de faire ça *aussi* dans le moteur de jeu.

The trick is easy to do in the animation editor: I can just use hardware OAM priorities and set ATTR2_PRIORITY(0) on those limbs that are on the "pulled layer". Unfortunately, that won't work in the game engine. I could end up with some limbs randomly appearing in secret passages or with other limbs randomly disapperaring when moving in front of complex background elements. The only viable option here is to re-order limbs in the Engine::sprites[] array. Let's see which is the best way to do it ...

Gauchers

Utiliser SEDS n'était déjà pas très facile pour un gaucher ... LEDS et AnimEDS, c'est encore pire. Or, mon frangin et mon filieul sont gauchers et clairement intéressés à faire leur propres petites maps...

si ça, c'est pas un tout-doux-il-t'aime, alors il n'y en a aucun sur ce blog :P

How sort of a godfather would I have been if I couldn't hear the crying voice of a little left-handed boy who's willing to draw maps with LEDS but struggle to use the current controls ...

So let's do a first try and allow swapping of L and R trigger buttons that should already help a lot. I'll need to meet a left-handed again to check whether keeping map navigation with R+DPAD sounds like a good idea or whether I should also swap DPAD and ABXY...

transanims: into the code

Maybe I should start a new branch once again: the amount of updates I brought to the code gets sensible, and it doesn't feel like it'd be a good idea to commit yet. The result is that I only keep on coding when I'm *the one* of my 3 daily computers which has the modified code :(

So far:

• it should be possible to add 'pop' when importing an animation (anim%u = spr:%x) to indicate that the animation should be POPed when it's done
• GobTransition has now a GobAnim field
• CompoundGob will reload_state (actually, the animation) if a POP instruction is encountered.
  

I still have to decide how the code will install a GobAnim on GobTransitions, and how following the transition will set up the transanim on the gob.

trine ?

I don't have a TV-console at home: my home and family is just not ready for that. Hopefully, from time to time, my brother show me the "new goodies" he downloaded from the PSN... such as Trine 2.
Graphically, it's just stunning. I could stay and just watch him playing, that would be no problem. The overall concept -- three characters with different abilities and puzzles to solve between action phases -- seduces me as well. I've be re-playing "the lost vickings" on GBA lately, and there's a good reason for that ;)

A défaut d'une console de salon, j'ai un frangin qui manque rarement de me faire profiter de ses dernière trouvailles dans les rayons Wii ou sur le PlayStation Network, en l'occurence le superbe "Trine 2". Trois personnages, un aspect puzzle très net, en principe le jeu à tout ce qu'il faut pour me plaire: si je me suis refait un "Lost Vickings" sur GBA dernièrement, ce n'est pas un hasard.
Pourtant, Trine déçoit: il est terriblement difficile de lire la scène. Oui, c'est beau, mais à décider de mettre le personnage et les objets d'avant plan en contre jour avec un modèle d'éclaire hyper-réaliste, l'oeil se perd. Olaf, Eric et toute leur clique gardent la même couleur où qu'ils soient, mais ici, le personnage devient une ombre dès qu'il arrive sous un porche, et pareil pour les ennemis.

Yet, playing Trine has been a bitter disappointment: it's extremely hard to *read* the scene. Granted, the environment is beautiful, but for some reasons, your characters gets easily lost here. I'm wondering whether that could be due to an over-realistic lightning model ... Olaf, Eric and their friend keeps the same tint wherever he goes, right ? but your Trine character will turn like a shadow as soon as he goes to a dark place... and so do your ennemies.

While Lost Vickings (and Trine 1) was a solo game, Trine 2 let my bro. take the second pad and give me a hand. That's a great idea, and I'm usually a huge fan of two-player games. Some trine characters, however, weren't designed for being part of a melee. Only one, actually. So if you're not playing as the barbarian/knight, you'll die repeatedly until he's done with goblin smashing.

This could have been only a minor issue if it turned puzzle solving into a social activity, but it does not. With two players, you're no longer trying to make sense of that ninja-rope-control-with-anologous stick... that's just useless since the wizard can create a magic crate and drop you wherever you want >_<. Off with your skills.

Nouvelle génération oblige, à Trine 2, mon frère peut prendre le 2eme contrôleur et incarner un second personnage. Excellente idée de manière générale: je suis fan des jeux vidéos coopératifs depuis nos parties endiablées de Loco 64... Mais le barbare mis à part, les personnages de Trine n'ont pas été étudiés pour le combat rapproché: que vous soyez mage où voleuse, attendez vous à rester à terre jusqu'à ce que le combat soit fini. Avec un peu de chance, vous trouverez un coin à l'abri d'où tendre des embuscades, mais n'y comptez pas trop.

Ça n'aurait été qu'un moindre mal si ça avait permis des scéances de remue-méninges familiales, mais là aussi, Trine 2 a raté la montre en or. Où est encore l'intérêt d'un personnage jouant les Tarzannes quand le mage peut vous transporter à peu près n'importe où sur l'écran rien qu'en créant une caisse magique, hmm ?

sprsplit.pl ; dumpanim.pl

SEDS, LEDS and AnimEDS use a dedicated file format: .spr, which is not very complicated, but specific to this project. The rationale is that, given the limited resources on the DS, I don't want to mess up with parsing or encoding of complex representation. I've got chunk of data, which have a given size and a given "type". This is how IFF files used to work back in the Amiga times, and I don't believe there is need for more over here.

However, with the toolset growing in features, hacking .spr files with an hex editor becomes tedious. A few weeks ago, I came up with two small tools -- sprsplit and sprmerge -- that can explode a .spr into one-file-per-chunk so that one could more easily e.g. replace a buggy animation with a sane one (from a previous file) without losing updates on the graphics themselves. Granted, a separate .anm file with the animations alone would have saved me the trouble :P

Bien: Bilou marche à gauche et à droite, escalade la règle, l'encre est animée et la "zone de collision principale" a fini de changer au moindre mouvement. Mis à part le côté 'bricolage' de la map et un nombre effrayant de messages de débug au démarrage, le niveau-test pour la school zone commence à devenir un brin plus propre. Dernier couac avant de m'intéresser de plus près aux "transanims": un à-coup dans la démarche de Bilou (alors que l'éditeur d'animation m'en fait un rendu parfaitement fluide ...)

Je sors donc un des petits outils développés dernièrement -- sprsplit -- pour "éclater" le fichier .spr correspondant en 'blocs logiques' histoire de repérer plus aisément l'animation qui cloche. Ensuite, un nouveau petit outil -- dumpanim -- va (enfin ;) me permettre de "décompiler" les commandes pour avoir la confirmation qu'une des commandes "délai 2 frames" n'a pas été convertie en "instruction pour l'éditeur d'animation" mais qu'elle reste bien présente dans les instructions adressées au moteur de jeu.

I've been one step further today, with a small "dumpanim" tool that present in a readable(?) format the content of an animation. It's crude, for sure, but less than mentally converting 0x2104fffe into UPDATE|COORDS|4|-2|-1 or 0x01000002 into CONTROL|DELAY|0x0002, etc. Here's how to make sense of its output:

• :**=xxxx : this is a "definition", such as page numbers, box size, etc. They're only read once
  
• .s?=yyyy : indicates that sprite #? should be changed
• .c?=xx,yy : indicates that sprite #? should be moved to (relative) coordinates xx,yy
• .m=xx,yy : indicates that the whole object should move by xx,yy
• !dxxxx : indicates that we should pause for xxxx frames before going on with playback
• !loop, !pop, !done : end-of-animation notifications
• // : an annotation for the editor (typically, how to place frames on the timeline when only the movement of the GOB guides the playback speed).
  

Now that AnimEDS' export code is fixed, I have great walk animations. Huzzah!

Mais bon, assez ri: la maison a besoin d'un coup de pouce pour se ranger ... entre les chaussettes et dumblador qui se bloque dans tous les coins, je vais devoir ajuster mes priorités :P

The Slope Bug (maybe?)

That bug has been haunting me for a while. Since I introduced slopes, actually. Even in Apple Assault, it may happen that you remain "stuck" at the bottom edge of a slope, no matter how hard you press the DPAD. Jumping is your only way out.

As I was trying to figure out how to allow Bilou Compound GOBs to climb up and down the ruler, I've found something suspicious that would be worth some more investigations:

• the "Walking" controller do not directly affect GOB's position. Instead, it updates cdata[STEPX] and cdata[STEPY] to indicate "how far away you should move";
• when we have a "selfmove" animation for the state, these STEP* remains accumulated until we have a value higher than the one required by the animation (reading->_.mspr.dx, for instance)
• climbing up slopes is allowed by realising that the animation does not provide a vertical move itself, but tolerates any vertical move you'd want to use. Some bits of .mspr.id control that.

Now, suppose your walker decides that you should move by -3,+3 pixels to follow a slope, but that your animation is only ready for moving by 2 pixels, you'll end up at -2,+3 and not at -2,+2 as you should. I haven't found out (yet) whether this is the real cause, and how that could lead to move Bilou into a wall (for instance), but it sure doesn't smell good.

fixed!

transition animations

Jusqu'ici, chaque "état" du comportement de Bilou pouvait avoir sa propre animation. Tomber, marcher, sauter, finir le niveau, etc. Tout ça fonctionne très bien dans Apple Assault, mais avec mon nouvel éditeur d'animation, j'ai envie de profiter de la liberté accrue pour donner encore un peu plus vie à Bilou: pirouette au sommet du saut, demi-tour moins brusques, etc.

Mais là, les choses ne vont plus comme prévu. Il y a de curieux soubresauts dans l'animation du saut de Bilou, qui tient plus du numéro de claquettes aériennes à la Snoopy que d'une performance d'athlète, je trouve. Le problème ? eh bien, j'ai créé une animation "chute" qui fait la transition entre la dernière image du saut et la position traditionnelle de Bilou qui tombe, les 2 pieds en avant et les mains en l'air. Le hic, c'est que dès qu'on entre dans un nouvel état, l'animation de cet état est lancée dès le départ. Donc, dès que je fais faire demi-tour à Bilou pendant son saut, il recommence l'animation sauter/tomber. Idem si je relâche ou ré-enfonce le bouton de saut.

Not so long ago, I was still convinced that having one animation per state would be just enough. Maybe some tricks would be needed to pause the animation until a certain speed would be reach or so, so that you could have funny transitions like turning back or fall-and-crash vs. fall-and-land. After the first attempt of re-doing Bilou animations with AnimEDS, I have to face the truth: that wouldn't work properly, and adding "cosmetic states" just for the purpose of having the desired animations would be a real nightmare: the state machine describing Bilou's behaviour is already quite complex.

Bref, il me faut un nouveau type d'animation, des animations de transition, qui sont déclenchées quand on passe d'un état à un autre, pour ensuite céder le pas à l'animation prévue pour l'état de destination. En théorie, il serait possible d'émuler ça avec des états supplémentaires et des "quitter l'état X quand l'animation est finie", mais pour cette fois, ce serait introduire une complexité tout à fait inutile et un fameux méli-mélo quand il s'agira de trouver les bugs dans un comportement aussi complexe. Bref, c'est ma prochaine intervention sur le moteur de jeu: faire en sorte que "stateJL->stateJR on event [DPAD RIGHT &] () :anim9" soit compris et retoucher les animations en fonction.

What I really need, is the ability to assign a specific animation to a transition. Not only you've got anim X when Bilou is idle and anim Y when Bilou walks, but you have also anim Z that will play when you switch from idle to walk and anim Z' that plays when you switch from walk to idle. As soon as Z or Z' is done, it automatically resumes with Y or X (resp.), and you're already in the "walk" state when Z starts playing. If you switch from fall to idle, however, neither Z nor Z' is played. Maybe you'll use Z" for that.

I've proceeded to some sketch and UML reasoning, and I think I figured out how to start coding that. I can't wait for the house to be clean so that I can start experimenting with some libgeds improvement ^_^

Frame.flipX()

If you look closely at the animation in last week's post, you'll note that there's something slightly odd with Dumblador's turn back. He's not doing a mirrored animation: position of the "body" against feet has changed, feet order isn't the same, and so on. That's because I just flipped the body and kept the feet animation identical from "walk left" to "walk right". Not out of laziness, but out of proper tool to do that.

It's now an experimental feature: holding (L) while touching the "flip horizontally" button doesn't flip the current limb, but the whole frame. Press UP/DOWN and apply it again on the next frame until you've flipped the whole animation, and dumblador will now walk the other way with a convincing animation.

Quelques ajustements, un petit mode "shift-click" supplémentaire sur un bouton, et me voilà (enfin) capable de retourner toute une animation dans AnimEDS ... et donc de faire marcher Bilou aussi bien vers la gauche que vers la droite. Ça n'aura pas été sans mal de tout peaufiner, notamment la position du "rectangle de collision" qui provoquait des plantages sans appels ici et là >_<

I'll still have to think about the appropriate way to do that with the interface, and then automate the process of flipping a whole animation... for instance through those "apply to this..last" or "apply to first..this" buttons.

What's funny about it is that I started an over-complicated version, and then squeezed it into a much simpler approach because I had forgot that the TIFrame (in-editor) use center-relative coordinates of limbs-center ... so most of my +width/2 additional stuff were useless and wrong. Maybe ohloh is right and maybe my code lacks documentation ^^"

edit: flipped some animations on the real hardware yesterday and experienced several guru meditation screens again ... I'm not yet done with that memory bug, or I've introduced a new one. I wish I could nail it down to a single, reproductible action sequence it appears when you switch from AnimWindow to FileWindow with Boxwidget displayed, and then back to AnimWindow.
edit+: it even happens in the emulator. "good". Now all I need to fix it is some spare time.
edit++: fixed

Best-of Pix'n'Love : Nutz

C'est sans aucun doute un des articles que j'ai préféré dans l'ensemble des pix'n'love. Plusieurs testeurs de Bilou: green zone demo ont noté une similitude avec le Mr Nutz "de Ocean" dans les années nonantes. En fait, il s'agit de l'oeuvre de deux personnes, un graphiste (Philippe Dessoly) et un programmeur (Pierre Adane), avec pour objectif principal de se faire plaisir... une sorte "d'Indie Game" avant l'heure, mais à une époque où ce genre de délire d'artiste pouvait finir en couverture de magazine et en version cartouche devant un grand présentoir en carton... Vous imaginez ça pour Spelunky ?

The interview of the team behind Mr Nutz is one of my favourite Pix'n'Love entries. The game started as the masterpiece of 2 people, one graphist and one coder who wanted to make the game they'd love. An indie title before indie was a thing at an era where it was everything and you could pitch a publisher with your demo and eventually have the game burnt into a cartridge, shown on the front page of the monthly magazines. It was an unprecendented era where some talented artist could get involved into game making without having to learn odds of graphical processor programming first. Mostly thanks to the drawing software of the Amiga.

C'est aussi une époque-charnière, où un graphiste/animateur formé pour le dessin animé pouvait enfin se mettre à faire du jeu vidéo sans nécessairement devoir d'abord apprendre en détail le fonctionnement du circuit graphique qui allait faire le rendu. Entre-autres sans doute parce que l'Amiga pouvait assez facilement réexploiter au niveau software les graphismes qui avaient été réalisés avec ses outils de dessins.

The interview has everything you could dream of: direct talk with the developers, screenshots and original design documents, focusing on "what we had in mind while we worked on the game", spiced up with trivias about what it was to work remotely when long-distance calls where neither cheap nor reliable and that you'd rather put floppies in a postal package after you checked the weather.

Au-delà du charisme de ce jeu (auquel je n'ai pourtant presque jamais joué), l'article reprend tous les éléments qui me tiennent à coeur: une vraie interview, appuyées par des documents d'époque de design du jeu, qui va à la rencontre de "ce qu'on avait en tête pendant qu'on a travaillé sur le jeu".

L'histoire des diskettes de graphismes relayées par chronopost m'a fait sourire: nous autres, à "PPP Team", c'était diskettes en poche jusqu'à l'Athénée et on essayait de se les échanger avant de devoir s'asseoir à côté d'un radiateur, sinon c'était le "bad sector" assuré. Puis plus tard, ç'a été "démonte le disque dur de 120Mo, emballe-le dans un essuie de vaisselle, et je le mets dans ma boîte à tartine. Grouille: on va louper le bus pour aller chez Tog et TBob!"

Je serais curieux de tomber sur les sources du jeu d'origine, tiens :)

edit: Oh. On nous fait une soirée-interview, tiens.

ordinogramme

Some boxes, some arrows, and proper abstraction level ... That remain imho the best analysis tool to apply (now from code shown on e-Ink :) before I start messing up with some refactoring. This time, it turns out that I _can_ use virtual method to encode TIFrame and TIControl differently given that I revise what arguments these functions receive and pack the dependencies into an 'encoder' state structure.

Mon patron appelle ça "des boi-boîtes et des flè-flèches", avec un léger dédain dans la voix. Moi, j'applique ça depuis le Simon's BASIC sur C64, et je trouve que ça continue à me rendre de fiers services. Trouver le juste niveau d'abstraction pour l'encodage des animations par AnimEDS, par exemple...

Once that has been done, I can easily fix the I_DELAY / I_MOVETO redundancy issue that slows down Bilou's new walk animation.

Oh, and I will still have to figure out the difference between 'move 2 0' and 'move 2 *' in the implementation if I want to restore rulers climbing.

A new Bilou is coming soon ...

here you go: new animations for Bilou under test. I still have lot of work to do before it gets really convincing, but it's clearly an animation improvement compared to the former, frame-by-frame animation, don't you think ?

• [done]that makes too much frame to toy with manual mirroring of the animations
• [done] all the animations are looping, which makes jumping look funny and the recovery infinitely long.
• [done] I have animations that guide movements, but not yet movements that regulate the speed of animations.
• [done]in "zoomed in mode", limb selection on the frame editor widget go completely crazy.
• [found] Bilou shouldn't get stuck on the ground like that
• [found] Why is nobody climbing up that ruler ?
• Dumblador should not got stuck on structure' edges
  
• [transanim] any statJ6->statJ6 transition reset the jump-take-off animation mid-air. I should have a way to tune that.
• [done] make sure my foot stops hurting

Eh bien, voici donc ces nouvelles animations à l'oeuvre -- c'est fou tout ce qu'on peut animer en une petite journée d'immobilisation quand la batterie de la DS est bien chargée ^^. C'est encore loin d'être parfait -- sinon, j'aurais fait une "release SchoolTest", mais ça prend forme... et ça me rallonge ma liste de choses à corriger ^^"

Ah, oui. J'en ai profité pour corriger cette histoire d'encre animée. Chouettos, mais vu que Bilou ne grimpe plus le long de la latte, on ne sait plus aller voir ce que ça donne ^^'

Tout ou rien

Ça être un rien plus long que prévu: il n'est pas possible de mélanger animation normale et composite pour un même GOB à l'heure actuelle: le nombre de sprites-membres et le décodeur d'animation sont fixés à l'instanciation en fonction de la première animation utilisée pour le GOB (son état initial).

Bilou's conversion to the new animation system has started. It's pretty funny and fairly fluid, although I failed to capture a decent video of it so far. It's still very buggy, I'm afraid.

C'est donc une grande partie du fichier bilou.cmd qu'il me faut mettre à jour, alors que AnimEDS n'est pas (encore) capable de "retourner" les animations lui-même.

Celà étant dit, dans l'éditeur d'animation, cette nouvelle démarche de Bilou donne franchement bien :)

10: GOTO 10

To be honest, I didn't expected it to be that complicated to fix, with a lot of trials and source reading (on my shinynew Cybook) to figure out why the code behaved differently than I expected. But at last, AnimEditor is now able to set "sticky limbs" on the first frame of an animation as well, which in turn enables me to craft a walking animation for Bilou in the editor.

I took the time to document the thing a bit more, too. The trick is that I have two representation for the animation: the tlist that is a sequence of TIFrame at specified time positions. This is just perfect for editing, as each frame fully encode the state without any reference to past/future state. The game engine needs just the opposite: a list of commands that instructs it to move that limb, change the sprite used by this one, then move the whole sprite by x,y pixels and wait for 3 vertical refreshes. All these commands are encode()d into flat 32-bit integers that are easy to read and write to files. When exporting them, frames are compared and updates are generated when required. When importing, the last generated frame is copied after every delay and altered to reflect the new state. So far so good.

Bien. Voilà un deuxième point règlé dans ma "roadmap de l'été": je peux créer une animation qui déplace le personnage à chaque "frame", y compris entre la dernière et la premère image, lors du "rebouclage". Je vais (enfin?) pouvoir améliorer la marche de Bilou grâce à AnimEDS :) Ça ne fut pas aussi simple que je l'avais pensé, celà dit ... croyez-moi (ou apprenez l'Anglais :)

It gets a little more complicated with the "sticky limbs" thing. The editor needs to know which limb sticks at the same place on-screen. You do that by selecting one of the limbs on the leftmost "limbtable" and then pressing the "time/move" button just between the frame editor and the animation preview (highlighted on screenshot), which initially just reads 'time'. If you decide to move dumblador's sticky foot further to the right, dumblador will move faster, and if you move the foot closer to dumblador's body, it will slow down its walk.

At the export, the offset of the sticky limb compared to the previous position of that limb is used to generate a "I_MOVETO" command. Devil was in the details, as always: when should the information be cleared when reading back, how to handle the commands when a TIControl item is selected, and whether the additional I_MOVETO has to be stored at the end of the serialised animation or before all the other update commands.

Well, I got it more or less sorted out now. All I'll need is improve the walk animation itself and patch bilou.cmd so that it makes good use of it.