Apres revue visuelle des atlas (suite 4), l’utilisateur a signale que tous les
sprites etaient OK sauf keys (les cartes-cles). Diagnostic + fix.
Cause identifiee
Le sprite keys est un cas particulier : ses 3 fichiers font 256 bytes
chacun dans original/INCLUDES/, et un dump hex a confirme que
keys.256pal == keys.ptr byte-a-byte (les 2 contiennent en fait un PTR
valide avec 16 colonnes de donnees, soit LONG[16] non-zero suivi de zero
padding jusqu’a 256 bytes).
C’est un bug du builder Amiga d’origine (FRAMEPICK / GAMELINKER) qui a
ecrase le .256pal avec le contenu du .ptr. Resultat dans le converter
Java : parseObjPalette lisait les bytes hauts d’offsets PTR comme indices
de palette globale (0x00, 0x02, 0x01, …) ce qui mappait vers les
couleurs sombres de la palette (entrees 0, 1, 2 = quasi noir/gris fonce).
D’ou couleurs cassees pour keys.
Pourquoi le check existant isDegenerateAsset ne suffisait pas
La fonction isDegenerateAsset exige que les 3 fichiers (.wad, .ptr,
.256pal) soient identiques pour skipper. Or pour keys, seuls 2 sur 3 le
sont (.256pal == .ptr), tandis que .wad contient les vraies donnees pixel
(c’est pourquoi 2 PNG keys_f0/f1.png etaient bien produits, mais avec
couleurs fausses).
Modifications
tools/convert/WadConverter.java :
– Nouvelle methode statique isPaletteDuplicateOfPtr(byte[], byte[]),
package-private pour testabilite.
– Le main detecte maintenant ce cas dans la boucle de conversion : si
palData == ptrData, on log un WARN et on bascule sur la palette
globale (globalPal directement, indices 0..31 utilises tels quels).
– Le format affiche est maintenant CORROMPU (= ptr) -> globalPal pour
ce cas (au lieu de simple 256B precedemment).
Tests : WadConverterPaletteTest.java (4 tests ajoutes)
Nouveaux tests dans le fichier existant :
– detectsKeysCaseWherePalEqualsPtr : reproduit le scenario keys avec
les vrais bytes du dump
– normalSpriteNotDetectedAsCorrupted : tailles differentes -> pas corrompu
– sameSizeButDifferentContentNotDetectedAsCorrupted : meme taille mais
contenu different -> pas corrompu (cas tres rare mais possible)
– nullInputsAreNotCorrupted : robustesse aux null (pal=null, ptr=null,
les deux null)
Resultat attendu
Les 2 frames assets/Textures/objects/keys/keys_f0.png et keys_f1.png
devraient maintenant montrer des couleurs vives (probablement les cartes-cles
rouge/bleue/jaune typiques d’AB3D2). Si l’apparence n’est toujours pas
satisfaisante visuellement, c’est que le mapping idx32 -> globalPal[idx32]
n’est pas le bon pour ce sprite specifique, et il faudra hardcoder un
mapping de couleurs different (improbable mais possible).
Aucune regression attendue sur les autres sprites : la condition
isPaletteDuplicateOfPtr ne se declenche que si les 2 buffers sont
byte-a-byte identiques, ce qui n’arrive pour aucun autre sprite.
A verifier
./gradlew test # 4 nouveaux tests + ceux existants
./gradlew convertWads # voir le log : "WARN: keys.256pal == keys.ptr"
./gradlew buildSpriteAtlas # regenerer l'atlas pour revue visuelle
Ouvrir assets/Textures/objects/keys/keys_atlas.png ou regarder dans le
master atlas _all_sprites.png.