Maintenant, poussez !

Armé de mes débuggeurs, je suis à la chasse aux petits "glitches" dans le jeu. Bilou reste parfois bloqué en bas d'une pente sans pouvoir continuer ... ou bien il ne sait pas s'introduire dans des conduits un peu plus étroits, etc. Sans doute des effets combinés du mouvement contrôlé par les animations et des conversions virgule-fixe-vers-entier.

If you have tracked updates of the last 'todo' post, you know I'm busy hunting and fixing all behaviour glitches in the current demo before I move forward to the Apple Assault mini-game. It's not that nice to have a gameplay where your hero might remain stuck at the bottom of a slope or where he's remaining stuck in narrow corners. Many of these oddities are side-effects of animation-controlled moves, which is intended to make Bilou better "fit" his world.

I had the opportunity last night to proceed to instruction-stepping of one such issue (g++ -O3 overdid it: it's impossible to check whether the algorithm is properly working at source code level anymore), which ended up with "Bilou's behaviour isn't buggy: it's incomplete!"

Après un retraçage complet au niveau assembleur (l'optimiseur de C++ fait trop bien son boulot: ce n'est plus possible de suivre l'algorithme au niveau symbolique), j'en arrive finalement à la conclusion que mes efforts pour "corriger le tir" sont vains: le déplacement de Bilou n'est pas buggué, il est juste incomplet. L'animation prévoit que l'on se déplace par pas de 2 pixels. Pas moyen d'y déroger. Si bilou n'est qu'à 1 pixel du mur, il ne s'en rapprochera jamais plus, mais du coup (cf capture d'écran), il ne saura pas sauter puisqu'il n'a pas complètement le champ libre vers le haut >_<.

Bref, pour résoudre ce problème, il me faudra une animation supplémentaire "pousser le mur" (que je pensais toutefois introduire plus tard) dans laquelle le déplacement est indépendant de l'animation (bin oui, quand il pousse, Bilou peut "patiner" sur place, ça ne gène pas). Du coup, je peux déplacer Bilou d'un-demi pixel à la fois s'il le faut pour qu'il vienne se coller au plus proche du mur ... sans y rester scotché ^^".

The 'walking' animation currently imposes that Bilou moves by two 2 pixels increments only. Whatever smaller speed I enforce at "controller" level or in the doslopes() function, they'll be accumulated until a move of at least two pixels is allowed. Of course, if you're only one pixel ahead of a wall, the move is impossible, and therefore it is cancelled. This happens at a point in the code where reasons of the move have been lost, so we're stuck in a dead-end situation. That gets even more troublesome if, such as on the screenshot, Bilou is trying to take a narrow corner: he can't move forward to align with the wall, but he can't jump until that alignment occurs.

Altogether, it looks like I'll have to introduce "wall-pushing" animation much earlier than I initially thought just to ensure that alignment to walls is possible. In such a "push" animation, I can decouple movement from animation frames and therefore I can move Bilou by half-a-pixel if needed, and noone will contest/modulate decisions made by controllers.