- il sautille un peu sur la descente de la règle au début
- … la caméra ça va je trouve
- ça manque d'effet sonore pour les sauts et rebonds
- le premier saut qu'on doit faire d'un crayon à l'autre avant le pot d'encre, je remarque qu'on peut pas y arriver si on ne se tourne pas d'abord dans la bonne direction
- La gomme du crayon c'est volontaire la possibilité de passer derrière ? le fait qu'on soit propulsé en sautant quand on est dessus n'a pas l'air de nous aider à passer. il faut prendre de l'élan je pense, ça complique les choses
Après une bonne heure d'inspection méticuleuse, j'arrive à la conclusion que le code du moteur de jeu, des contrôleurs etc. est 100% clean: c'est dans l'animation que ça coince. Pour une raison encore inconnue, une des étapes d'animation force le déplacement à être horizontal plutôt que de s'adapter à la pente en cours ... bizarre, bizarre.
Je ressors donc mon "extracteur d'animation en vrac (à perforation en vrille): il y a en effet quelque-chose de louche avec les animations de marche de Bilou. Les étapes d'animations qui se comportent bizarrement ont un bit "déplacement vertical autorisé" qui reste à zéro. Chose intéressante: le pendat (qui était incapable de suivre les pentes) a systématiquement ce bit à zéro. Dumblador, lui a son bit "déplacement vertical autorisé" mis pour chaque étape.
J'aurais été bien incapable de dire en aveugle à ma fée quelle manipulation elle aurait du faire pour changer ce règlage dans AnimEDS, ce qui signifie que c'est un des contrôles-candidats pour un menu déroulant ou quelque-chose de ce genre.
En fait, c'est le petit "!" devant "y" qui doit être retiré pour "déverouiller" l'animation verticalement.
Mais alors ? Si ce sont des règlages au niveau de l'animation (et pas d'une étape isolée), pourquoi cet étrange étape verouillée dans la marche de Bilou qui ne l'est pas pour le reste ? Sans doute parce qu'il s'agit de la liste de commandes générée pour permettre de boucler la boucle, et que son code n'a probablement pas eu droit à sa mise à jour (ouuuuh ^^").
J'édite l'animation en hexadécimal dans Midnight Commander ... Je recompile à cloche pied ... Bilou retient son souffle: c'est l'heure du test fatidique ... attente insupportable de 15 seconde pendant que la caméra re-traverse le niveau à contre sens pour venir se centrer sur Bilou au départ.
Ah oui! Bien mieux! La descente est fluide, la remontée aussi... Il me reste à aller corriger AnimEDS, donc.
Il y a eu d'autres commentaires de Joke, et une longue discussion à propos du rebond sur la gomme, mais ça, ce sera pour un autre article, je pense.
- [ongoing, donné 3 frames de plus avant que Bilou ne se fasse propulser -- les autres approches étaient catastrophiques]
- si la caméra suivait pendant le saut, tu pense que ça rendrait mal ? (caméra est plus lente que le personnage sur l'axe vertical, du genre, la vitesse qu'elle a déjà pour monter lorsqu'on tombe sur une plateforme plus haute)
- [done] j'arrive à faire disparaître temporairement le sprite de bilou en pressant B en plein saut (clignoter, en fait)
- pour les mouvements de caméras, tu pourrais essayer d'adoucir le départ et la fin du déplacement pour voir, du genre une accélération et une décélération progressive
2 comments:
: )
toujours passer en mode "à perforation en vrille"
Je suis enchanté que mon pinaillage ait déjà entrainé quelques solutions prometteuses ! =D
J'ai hâte de retester. ;)
Post a Comment