Session 132duodecimus (suite 3) — Fix sprites FX (couleurs echangees pour tirs/explosions)

L’utilisateur a signale que les sprites de tirs, explosions et balles
(BIGBULLET, Explosion, peut-etre ROCKETS) avaient des couleurs echangees.
Diagnostic + fix.

Cause identifiee

Les fichiers .256pal ont deux formats differents selon le type de sprite :

Le code Java avant fix lisait TOUS les fichiers comme « format simple »
({@code palData[i2]} = HIGH byte du WORD a l’offset i2 = 32 premiers bytes
de la table). Pour les fichiers de 8192 bytes, ces 32 premiers bytes
appartiennent a la ligne 0 horizontale de la table de blending
(blendTable[0..31] = blend du sprite color 0 sur ecran color 0..31), ce qui
donne des couleurs aleatoires totalement incoherentes avec les vraies couleurs
du sprite. D’ou couleurs echangees.

Reference ASM (objdrawhires.s::draw_bitmap_additive)

 move.l  draw_BasePalPtr_l, a4    ; a4 = blendTable (32*256 bytes)
 ; ... extraction idx5 du WAD ...
 lsl.w   #8, d0                   ; d0 = idx5 << 8
 move.b  (a6), d0                 ; d0 |= screen_color
 move.b  (a4, d0.w), (a6)         ; nouveau pixel = blendTable[d0]

La table fait 32 x 256 = 8192 bytes : pour chaque couleur 5-bit du sprite (32
lignes), 256 mappings selon la couleur d’ecran (le pixel deja present sous le
sprite). Le moteur runtime utilise ca pour le blending additif (lueur
transparente).

Pour un preview statique (PNG sans fond), on prend la colonne 0 :
{@code globalIdx = blendTable[idx5 * 256 + 0]}, soit le rendu sur fond noir,
qui represente la couleur « pure » du sprite isole.

Modifications

tools/convert/WadConverter.java :
– parseObjPalette() detecte maintenant automatiquement le format additif
(palData.length >= 8192) et delegue a parseAdditivePalette(). Sinon
comportement simple (HIGH byte) preserve, donc aucune regression sur les
sprites qui marchaient deja (alien2, pickups, etc.).
– Nouvelle methode parseAdditivePalette(byte[], int[]) : extrait la colonne
0 de chaque ligne de la table 32 x 256.
– Le main affiche maintenant le format detecte pour chaque sprite :
Format pal: additif 8192B ou simple 2048B ou compact NNB.

Nouveau fichier tools/diagnose/SpritePaletteAnalyzer.java :
– Outil de diagnostic qui scanne un dossier (original/INCLUDES par defaut)
et affiche pour chaque .256pal :
– Taille et format detecte (heuristique sur la taille)
– Stats HIGH vs LOW byte sur les 32 premieres entrees
– Hex dump des 16 premiers bytes
– Utile pour verifier que la detection automatique est correcte sur des
fichiers nouveaux ou modifies.

build.gradle : nouvelle tache dumpSpritePalettes.

./gradlew dumpSpritePalettes              # par defaut original/INCLUDES
./gradlew dumpSpritePalettes -Pdir=original/hqn

Tests : WadConverterPaletteTest.java (8 tests)

Nouveau fichier src/test/java/com/ab3d2/tools/convert/. Couvre :
– Format simple (2048B) : lecture HIGH byte de chaque WORD
– Verification que seule la table 0 est utilisee (les autres tables de
luminosite ne perturbent pas)
– Format additif (8192B) : detection automatique, extraction de la colonne 0,
ignorence des autres colonnes (1..255 = blending values)
– Boundary 8192 : verifie que 8192 declenche bien la voie additive
– Format compact (32B) : un byte par entree
– Cas null / vide / palette manquante

Sprites attendus a etre fixes

• BIGBULLET (8192B) : couleurs maintenant correctes (auparavant la 1ere
  ligne de la table additive etait lue par erreur)
• Explosion (8192B) : idem

Sprites possiblement encore incorrects (a verifier)

• ROCKETS (2048B) : si l’utilisateur trouve toujours mauvais, c’est un
  autre probleme (peut-etre brightness level ou type de lumiere). Les rockets
  sont rendus par draw_bitmap_glare qui fait aussi un blending mais avec
  un format different.
• glare (2048B) : meme remarque que ROCKETS.

Si l’utilisateur confirme que les sprites concernes sont uniquement ceux a
8192 bytes (BIGBULLET, Explosion), le fix est complet. Sinon, une analyse plus
poussee de draw_bitmap_glare sera necessaire.

A verifier

./gradlew test                     # 8 nouveaux tests doivent passer
./gradlew dumpSpritePalettes       # voir les formats detectes
./gradlew convertWads              # regenere les sprites

Observer visuellement :
1. assets/Textures/objects/bigbullet/bigbullet_f*.png et explosion/*.png
doivent montrer des couleurs coherentes (jaune/rouge/blanc pour
l’explosion, blanc-bleu pour bigbullet).
2. Le dump du convertisseur affiche maintenant Format pal: additif 8192B
pour ces deux sprites.
3. Aucune regression sur les autres sprites : alien2, pickups, lamps, glare,
rockets, splutch, keys doivent rester identiques.