Session 117 — NOFF confirme pour worm (20) et robotright (24)

Confirmation visuelle

Apres l’export multi-candidates de la session 116, l’inspection des frames a
revele les valeurs correctes :

• {@code worm} : NOFF=20 = 5 vues directionnelles * 4 frames d’animation
• f0-f4 : vue de face (visage et bras visibles)
• f5-f9 : vue 3/4 face
• f10-f14 : vue dos vue de dessus (silhouette pliee)
• f15-f19 : vue de dos

• {@code totalCols = 1800 / 20 = 90 (WOFF)} sans residu

• {@code robotright} : NOFF=24 = 4 vues directionnelles * 6 frames d’animation

• f0-f5 : face avec arme a droite
• f6-f11 : 3/4 droite avec arme avant
• f12-f17 : dos avec arme a gauche
• f18-f23 : 3/4 gauche
• {@code totalCols = 3072 / 24 = 128 (WOFF)} sans residu

Note : l’attente initiale de « 5 vues * 4 frames partout » etait un biais.
robotright utilise un schema different (4 vues * 6 frames) probablement
parce qu’il a une animation de marche/tir plus elaboree. La verification
de divisibilite {@code totalCols % NOFF == 0} aurait flag NOFF=20 comme
invalide pour robotright (1800/20 ok, mais 3072/20 = 153.6 ne l’est pas).

Le pattern « vues * frames_anim » reste coherent pour les deux.

Note : la spritesheet n’a jamais ete generee

La session 116 prevoyait un fichier <name>_sheet.png de la spritesheet
complete (1800×100 pour worm) mais aucun n’a ete produit — probablement
{@code renderFrameHqn} a une limite stricte sur la largeur d’une frame ou
une exception est levee silencieusement quand la frame demandee couvre
toute la table PTR. Pas approfondi car les frames individuelles sont
correctement generees et la valeur NOFF correcte est maintenant identifiee.

Fix : NOFF fige + suppression du code multi-candidates

{@code WadConverter.convertObjectStandalone} simplifiee :
– Plus de spritesheet generee (inutile une fois NOFF connu)
– Plus de boucle sur des candidates (NOFF est un parametre simple)
– Validation : {@code totalCols % NOFF == 0} avec erreur explicite

Dans la boucle {@code extraAlienSprites}, NOFF est fige a 20 pour
{@code worm} et {@code robotright}. Liberte pour ajouter d’autres sprites
HQN avec un NOFF different (la signature reste flexible).

Validation attendue

Apres re-export par {@code ./gradlew convertWads} :

[EXTRA] TKG1:HQN/WORM
  WAD=95527 bytes, PTR=7200 bytes, 256pal=1024 bytes, HQN=180000 bytes
  Frames: NOFF=20 WOFF=90 HOFF=100 (totalCols=1800)
  Mode HQN: 1 byte/pixel, index direct
  -> 20 sprites PNG

[EXTRA] TKG1:HQN/ROBOTRIGHT
  WAD=233536 bytes, PTR=12288 bytes, 256pal=1024 bytes, HQN=393216 bytes
  Frames: NOFF=24 WOFF=128 HOFF=128 (totalCols=3072)
  Mode HQN: 1 byte/pixel, index direct
  -> 24 sprites PNG

Les deux sprites passent maintenant la verification {@code totalCols % NOFF == 0}
sans residu. Les fichiers PNG ont des noms standards {@code worm_f0..f19.png}
et {@code robotright_f0..f23.png} sans prefixe {@code _n*}.