Pas si circulaire ...

Bon, j'essaie de mettre au point le fait de s'accrocher aux racines, et ça malgré le fait que j'ai noté quelque part "oui, ça ne marche pas parfaitement, mais c'est amplement suffisant pour faire le tour des niveaux sans ce prendre la tête".

C'est sans doute ce que je ferai dès demain, mais il faudra que j'y revienne et que je corrige un peu tout ça. Un composant "reste dans le cercle" avec un comportement cahotique, c'est marrant pour SpongeBop à cause de son élastique ... mais pour les lianes qui pendent ? les signets ? les ponts ? les boss ?

Technically, it would be nice to have Bilou reusing the "stay within radius" behaviour of SpongeBop when he's hanging at a root. Just have a smaller radius, show his hands grasping the root and voilà (oh, and remove the white polygons, please). That would work if that RadiusController wasn't randomly jerking up. Jerky monster with funny tik-tokking eyes is fun. But a jerky bookmark ? A jerky vine ? that looks suspiciously close to a bug to me

I had already fixed a more serious bug last week, and somewhere on some note book, I wrote down that "jerkiness shouldn't hinder levels traversal. Keep it as is and keep going". And yet there I am. Maybe this number shouldn't be that high ? Maybe that thing is wrong ... What does it look like in DDD?

Je vous ajoute deux petites capture-gif pour que vous vous rendiez compte si vous n'êtes pas allés vous promener sur mastodon ces derniers temps ... une où ça va pas trop mal (ci-dessous) et une ou ça part dans tous les sens (ci-contre)

Dans les deux cas, je ne donne aucunes consignes avec la manette. c'est juste "l'énergie de départ" qui est hors contrôle ... ou un problème d'arrondis qui s'accumulent ... ou quelque-chose de plus fondamental.

J'ai fini par rajouter un printf("%vx,vy + %corr_vx,corr_vy @%extra_radius") dans le code et faire cracher des tonnes de chiffres pendant que ça partait dans tous les sens (le debugging step-by-step, sur un problème comme ça ne donnait rien). Contrairement à ce à quoi je me serais attendu, on a très peu de "brusque augmentation du vecteur-vitesse" ... par contre, on a régulièrement un vecteur plutôt important (correction d'1 ou 2 pixels) parfois pendant 2 frames d'affilée. Dans un setup où la gravité met 8 frames à augmenter d'1px/frame, ça veut dire que Bilou va facilement nous faire un petit bond de la taille d'un caillou quand ça se produit.

The 2 screenshots above show the state as of ScreenshotSaturday, 5PM. I guess I don't have to convince you that it would look broken, if the game was doing that while you're not even pressing any button of your DS. I added print statement, revealing adjustments performed to stay within the radius (step-by-step debugging doesn't really work for such use cases), and even shooting a video of those lines so that I could time-travel and see what were the causes of sudden bumps... Except that there were no "sudden huge speed". Instead, there were multiple frames with 1 or 2 pixel-per-frame corrections, but that was already fairly strong for 1/8th-of-a-pixel-per-frame gravity. At 8PM, I had given up: it would require a complete rewrite to get stable behaviour, for sure.

Alors voilà ... j'ai copié le code de RadiusController::think dans un carnet pour pouvoir le comprendre et l'annoter ... j'ai voyagé dans le temps avec les captures .gif et analysé les chiffres que mon print avait produit et ça me donne le sentiment un peu désagréable qu'il n'y a rien de corrigeable dans ce code, parce que l'impact sur la vitesse persiste plus longtemps. Peut-être faudrait-il corriger directement la position, mais alors on perdrait la transformation de la chute en un mouvement de balancier...

edit: vous l'avez lu, j'étais sur le point de jeter l'éponge ... puis le lendemain matin, j'ai voulu tenter quelque-chose quand-même: et si les valeurs dx et dy que j'utilise pour vérifier si dx²+dy²<radius² n'étaient pas exprimées en pixels mais en subpixels ... pas en 256èmes comme la vitesse parce qu'il faudra quand-même les multiplier et que ça ne déborde pas ... mais des 16èmes de pixels ? Eh bien, avec ça, ça donne quelque-chose de beaucoup plus convaincant... je vous remet une mini-animation sur le côté. Il y a un peu de vibration résiduelle mais rien de vraiment choquant. Et ça malgré que Bilou partait avec un mouvement du genre à faire des bonds dans tous les sens au commit précédent.

But as I started my Sunday, I wanted to try something before rolling back to where I was on Friday: adjust the algorithm so that it would work with sub-pixel precision. 16th of pixels, to be precise, just the intermediate between pixel coordinates and current 256th of pixels used for speeds and entity positions by the engine. And ... well ... it turns out I now have something that converges towards a stable state. It's a bit sad for Spongebop... I'll have to try and find a way to turn of stabilization for them ^^".

Il me reste à trouver un moyen de rendre ça paramétrable, des signets qui ne soient pas élastiques et des spongebop qui le soient (la pauvre, obliger de circuler le long d'un parfait arc de cercle, c'est vraiment la dictature de SquareRoot ... je ne le lui souhaite pas).

edit²: le changement d'échelle (subpixel 12.4) suffit à lui seul pour avoir une éponge qui suit une trajectoire toute circulaire ... mais pour Bilou qui peut débarquer avec un vecteur-vitesse quelconque, il faut bien tous les petits ajustements. ça sent le code split, parce qu'il n'y aura rien à paramétrer ...