Aller au contenu principal

Session 97 — Portes : ASM-fidele enfin

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 :

  1. Les vrais ZDoorWalls sont les murs des couloirs voisins de la zone-porte,
    ceux qui ont otherZone = doorZoneId dans le JSON.
  2. Ils ont DEJA leur propre clipIdx qui pointe vers la BONNE texture
    (ex. clipIdx=5 = wall_05_chevrondoor.png pour la porte zone 5).
  3. Le gfxOfs du JSON (« walls » sous-bloc des doors) N’EST PAS un texIndex !
    C’est juste un BYTE OFFSET dans le buffer Lvl_GraphicsPtr pour que la
    routine ASM DoorRoutine puisse retrouver la struct graphique du wall et
    patcher dynamiquement son topWallH/botWallH/yOffset a runtime.
  4. L’animation reelle : la routine modifie ZoneT_Roof_l de la zone-porte
    (le PLAFOND descend pour fermer, monte pour ouvrir). Les ZDoorWalls
    voient leur topWallH patche 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 :

  1. Pendant la boucle des zones-couloirs : si un wall a otherZone=doorZone
    ET son edge est dans la liste des walls de la porte (via parseDoorZoneEdges),
    c’est un ZDoorWall.
  2. On utilise SON PROPRE clipIdx comme texture (pas le gfxOfs interprete).
  3. On utilise SES PROPRES coordonnees (leftPt, rightPt) pour la geometrie,
    pas les edges de la zone-porte.
  4. 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 parseDoorFirstGfx et doorZoneGfx (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 : makeDoorSegGeo recalcule L_pixels et
    wallH_pixels pour avoir la meme echelle que tileW/tileH (pixels)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *