Le diagnostic ASM definitif
Apres relecture COMPLETE du fichier newanims.s (DoorRoutine ligne 1900+ +
zone_liftable.h), le mecanisme reel des portes a ete compris :
- Les vrais ZDoorWalls sont les murs des couloirs voisins de la zone-porte,
ceux qui ontotherZone = doorZoneIddans le JSON. - Ils ont DEJA leur propre
clipIdxqui pointe vers la BONNE texture
(ex.clipIdx=5=wall_05_chevrondoor.pngpour la porte zone 5). - Le
gfxOfsdu JSON (« walls » sous-bloc des doors) N’EST PAS un texIndex !
C’est juste un BYTE OFFSET dans le bufferLvl_GraphicsPtrpour que la
routine ASMDoorRoutinepuisse retrouver la struct graphique du wall et
patcher dynamiquement sontopWallH/botWallH/yOffseta runtime. - L’animation reelle : la routine modifie
ZoneT_Roof_lde la zone-porte
(le PLAFOND descend pour fermer, monte pour ouvrir). Les ZDoorWalls
voient leurtopWallHpatche en consequence -> visuellement le panneau
se reduit en hauteur.
Erreur des sessions 93-96
Mon code precedent interpretait gfxOfs comme :
texIndex = (gfxOfs >> 16) & 0xFFFF
yOffset = gfxOfs & 0xFF
C’est COMPLETEMENT FAUX. Les valeurs gfxOfs (2142, 3576, etc.) decalees de 16
bits donnent 0 ou des nombres absurdes. La texture utilisee finissait par etre
la premiere du tableau (clipIdx=0 = stonewall) ou une fallback rose.
Resultat: textures grises/marron, panneaux dupliques, animations bizarres.
Solution Session 97
Refactor complet de la detection ZDoorWall dans LevelSceneBuilder :
- Pendant la boucle des zones-couloirs : si un wall a
otherZone=doorZone
ET son edge est dans la liste des walls de la porte (viaparseDoorZoneEdges),
c’est un ZDoorWall. - On utilise SON PROPRE clipIdx comme texture (pas le gfxOfs interprete).
- On utilise SES PROPRES coordonnees (leftPt, rightPt) pour la geometrie,
pas les edges de la zone-porte. - Les 2 ZDoorWalls (un de chaque cote du couloir) sont rendus chacun comme
un quad separe -> on voit la porte des 2 cotes.
Fichiers modifies
tools/LevelSceneBuilder.java:- Suppression de la boucle de construction du « cube » (session 96)
- Detection ZDoorWall + ajout direct dans DoorAccum.segs avec clipIdx du wall
- Nouvelle methode
parseDoorZoneEdges(json)(zoneId -> Set) - Suppression de la deduplication des segments (les 2 faces sont voulues)
- Suppression de l’usage de
parseDoorFirstGfxetdoorZoneGfx(inutiles)
Bug additionnel : UV mapping incorrect dans makeDoorSegGeo
Apres le refactor, la texture s’affichait toujours mal (degrade horizontal
blanc/marron). Cause : makeDoorSegGeo calculait uM = L / tileW ou L
etait en unites JME (deja /SCALE) alors que tileW etait en pixels Amiga.
Resultat : facteur 32x trop petit -> texture etiree 32 fois en horizontal,
on voyait 1-2 pixels etires sur tout le mur.
Fix : reconvertir L en pixels via L_pixels = L * SCALE avant le calcul UV.
buildWallGeo (murs normaux) faisait deja le bon calcul car il operait avant
la division par SCALE.
Comportement valide
- Porte zone 5 (standard) : panneau jaune/noir hazard chevrondoor qui monte ✓
- Porte zone 132 (rouge large) : openSpeed=4 (lent), top=-704 (haut), avec
sa texture clipIdx=5 = chevrondoor egalement - Toutes les autres portes (30, 11, 54, 48, 52, 57, 96, 68, 74) : meme mecanisme
Fichiers modifies (ajout fix UV)
tools/LevelSceneBuilder.java:makeDoorSegGeorecalculeL_pixelset
wallH_pixelspour avoir la meme echelle quetileW/tileH(pixels)