Gotcha!

Bon, bin voilà. J'ai l'affichage des zones de collisions et j'ai du coup pu mettre le doigt sur le problème observé avec les Applemen qui a motivé tout ça. En bleu, la zone "fragile" de Bilou, en vert sa zone d'attaque. En rouge, la zone d'attaque de l'Appleman et en bleu clair sa propre zone "fragile". Pour pouvoir assommer l'Appleman, il faut que vert et bleu-clair se recouvrent sans que bleu et rouge ne se touchent. Le carré bleu clair au milieu de la zone d'attaque de l'appleman est évidemment une erreur dans le script du jeu ...

Well, here we go. Collision areas are displayed, updated as I proceed with step-by-step detection and coloured depending on their role. Blue is Bilou's weak zone, green is Bilou's attack zone. Red is monster attack and cyan is monster weakspot. Only 4 zones can be shown at once with InspectorWidget, so you've got to click the "a" and "p" of the appropriate monster to trigger the correct display ... that's still manual. You also have to "guess" who's who using monsters coordinates and state number.

I bet i could keep improving the UI, put coordinates in smaller font around the sprites, and have the sprites of the monsters shown in the "boxes" as on the sketch'up. But who'd care ? I pin-pointed the bug that made the applemen so hard to defeat: with the "weak spot" (cyan) in the middle of the "attack area" (red), how could I possibly stomp it without having Bilou (blue) entering that attack area ? That's only possible if Bilou's speed is high enough, etc. I think I'll rather fix *that* instead, and then keep on working towards either Nuts'n'Bolts or Apple Assault project.

ATTR0_ROTSCALE : partie I

Tout comme le GBA et la SNES, la DS est capable de zoom et "rotations" sur un sprite. Une fonction quelque peu obscure, sans doute parce que liée à une implémentation hardware alors qu'on serait tenté de penser "transformations géométriques" (comme dans le cas d'OpenGL) ou "programme de rendu". Eh bin non. Puisque je projette de me servir de sprites aussi pour la visualisation des zones de collisions pour mon InspectorWidget, voilà un peu de bidouille pour identifier les quelques points importants à prendre en compte. Mon "sprite de base" est une sorte de grille/radiateur noir dans une zone de 16x16.

Engine::sprites[oam].attribute[0]=ATTR0_ROTSCALE|ATTR0_ROTSCALE_DOUBLE|
   ATTR0_TYPE_BLENDED|ATTR0_SQUARE|y;
Engine::sprites[oam].attribute[1]=ATTR1_ROTDATA(oarot)|ATTR1_SIZE_16|x;
pSpriteRotation sr = Engine::spriteRotations + oarot;
sr->hdx=0x100; sr->hdy=0x0; // 8.8 fixed point : 0x100 is 1.00 here
sr->vdx=0x0; sr->vdy=0x100;

ROTSCALE_DOUBLE affecte la manière dont les coordonnées sont interprétées. C'est la zone de visualisation -- de 32x32 ici, matérialisée par les # blancs -- qui aura ses coordonnées en (x,y). Le sprite proprement dit, lui, verra son centre coïncider avec le centre de cette zone.
Si je donne les paramètres (hdx,hdy,vdx,vdy) = (1,0,0,1) -- ce qui correspond à un affichage sans aucune transformation -- mon sprite apparaîtra donc w/2 pixels plus à droite et h/2 pixels plus bas que les coordonnées (x,y) que je lui fixe.

A noter que [hv]d[xy] indique "de combien avancer (en X et Y) dans la "texture" du sprite lorsqu'on avance d'1 pixel Horizontalement ou Verticalement sur l'écran. Du coup, un zoom grossissant s'obtient avec des valeurs de hdx plus petites que 1.

Si je zoome (0.5,0,0,0.5) puis (0.25,0,0,0.25), le centre de mon sprite continue effectivement à coïncider avec le centre du "viseur". En revanche, impossible de sortir de la "zone de visibilité" de 32x32, même avec un facteur de zoom (4x) qui devrait m'afficher un sprite de 64x64, je ne vois plus que le centre de l'image.

En clair, le hardware permettra sans problème de légère déformations, comme celles subies par Morton Koopa Jr., et n'importe qu'elle réduction de taille (jusqu'à 256 fois plus petit ;), mais pour un zoom prend-toi-ça-dans-les-dents tels qu'on en a vu dans le combat contre Bowser dans SMW ou dans Turtles in Time, il faut ruser...

• soit en utilisant plus de sprites,
• soit en prenant des sprites plus gros que ce qui est nécessaire (p.ex. 64x64), zoomés de manière logicielle et rapetissés artificiellement par le hardware -- probablement la solution pour mes zones de collision,
• soit (à mon avis plus plausible) en utilisant un fond plutôt qu'un sprite pour le boss. Ca s'est régulièrement vu sur NES où les sprites avait des tailles ridicule (8x8 ou 8x16 :P)

PS: tests réalisés sous Desmume 0.9.4 (linux) et confirmés par le hardware.