Landing bug, from the state machine

Since the introduction of 1st September release, I observed curious behaviours with Bilou landing. First, it could occur that Bilou looks "dislocated" just when landing, which would last for a few frames before he starts walking. That can be explained by the fact the OAMs the hardware uses have received new graphics, but still with the ordering (and layout) of the last frame. It "sticks" that way because the "walking" animation starts with a 'MOVE' command, which actually instructs the game engine to wait for the GOB to have accumulated sufficient amount of inertia to be able to "step" by 3 pixels to the right. This has been fixed just yesterday.

La dernière release a un bug bizarre: quand Bilou atterrit, on dirait qu'il se retrouvé désartibulé un moment (cf. capture), puis tout revient dans l'ordre au moment où il commence à marcher. la raison, c'est qu'au moment de changer d'animation, les sprites hardware ont déjà reçu leurs nouvelles images, mais leur coordonnées (et leur ordre d'affichage) reste inchangé. Si ça ne se voit pas la plupart du temps, c'est que la prochaine image n'est généralement pas bien loin, sauf dans le cas de l'animation de la marche qui commence par une commande MOVE indiquant au moteur d'attendre que le personnage ait accumulé assez de "crédit de déplacement" pour pouvoir faire le premier 'pas' (ici de 3 pixels).

But there's another, harder to catch, subtle bug that hides in the "state machine" that controls Bilou, more precisely between "fall", "idle" and "walk" states. In those rare cases, Bilou lands in "walking" state although you're no longer pressing the DPAD in any direction. He keeps walking forward at a very slow rate (~1px/second), unless some block prevents him from doing so or you press some button on your DS.

There sure are curious things in that state machine, such as clearing the DPAD memory before entering idle state so that you force dpadController to generate an event for "getting pressed". I have the feeling that none of this remains useful now that I have "impact speed" variables that can offer a direct fall->walk transition.

It looks like the bug was in the momentum controller code, however: it would fail to decrease any speed below 8/256th of pixel per frame, and would generate no event for "reaching speed zero".

Un autre effet bizarre lié à un bug dans la machine d'états de Bilou se déclenche quand l'atterrissage se fait alors qu'on vient de relâcher le DPAD. Bilou donne alors l'impression d'avancer trèèèèès leeennnteeeemmeeeennt avant de s'arrêter complètement. Il faudra sans doute que j'aille corriger dpadController pour qu'il perde la mémoire des dernière directions avant d'entrer dans l'état 'attente'. Je ne devrais plus en avoir besoin maintenant que je peux capturer la 'vitesse d'impact' quand on atterrit. Ah, et un p'tit bug dans le contrôleur d'inertie qui oubliait de me signaler l'arrivée à une vitesse nulle, restant bloqué à 8/256e de pixel par frame.

PS: the '90,000 views' bar has been hit this morning, according to Google, but I strongly doubt that it's true. Google is terribly sensitive to all those page-ranking cheaters that pretend they're referencing you just to attract your attention to their web domain.