Aller au contenu principal

Session 124 — Phase A (revision) : correction inversion luminosite

Probleme observe

Apres la mise en place initiale de la phase A (vertex-color baked,
Unshaded.j3md), l’utilisateur a constate que toutes les pieces apparaissaient
uniformement eclairees, sans variation visible (cf. screenshot zone 3 du level
A). Aucun gradient de luminosite, aucun couloir sombre, aucun effet de halo.

Cause

Apres relecture de l’ASM (hireswall.s:299-313), le mapping wallBright →
paletteOffset
est tel que plus haut = plus clair (l’ASM ajoute
BrightnessScaleTable[wallBright>>7] a Draw_PalettePtr_l, ce qui decale
vers les couleurs plus claires). Or la formule de la session 124 initiale
faisait l’inverse : intensity = 1 - (wallBright - BASE) / NORMALIZER.
Resultat :
– Zones avec zone.brightness=+20 (= claires dans le binaire) etaient
rendues sombres (intensity ≈ 0.10).
– Zones avec zone.brightness=-20 (= sombres) etaient rendues claires.
– Inversion totale.

Modifications

world/BrightnessCalc.java
– Suppression des constantes BASE et NORMALIZER.
– Nouvelles constantes WB_MIN=260f, WB_MAX=365f qui bornent la plage
effective de wallBright = abs(Rb_point) + Wb. Calibrees empiriquement
depuis l’analyse de la formule ASM (Lb in -20..+20, brightness in -20..+20).
MIN_INTENSITY releve de 0.10 à 0.30 (zones tres sombres restent lisibles).
rbToIntensity() refonde : rampe lineaire NON-INVERSEE entre WB_MIN et
WB_MAX. Plus wallBright est eleve, plus intensity tend vers 1.0.
– Calibration : zone neutre (Lb=0, Wb=0, wallBright=300) → intensity ≈ 0.57.
Lampe pleine puissance (Lb=20, Wb=32, wallBright=363) → intensity ≈ 0.99.
Zone tres sombre (Lb=0, Wb=-32, wallBright=268) → intensity ≈ 0.35.

tools/LevelSceneBuilder.java
– Ajout de stats de luminosite affichees a la fin de chaque buildScene() :
Wb[min/avg/max] par zone, et Lb[min/max] parmi les pointBrights
non-nuls. Permet de diagnostiquer si le binaire contient des variations
utiles pour la phase A (statique) ou si la majorite des effets sont en
phase B (animations – non encore implementee).

Limitations restantes (= phase B a venir)

  • Les sols-verre qui pulsent ne sont PAS visibles : leur luminosite vient
    des animations Amiga (BrightPulse1-5, BrightFlicker1-2 dans newanims.s),
    qui modifient pointBrights[i] en temps reel chaque frame. La phase A
    capture la valeur a phase=0 seulement, qui correspond souvent a Lb=0
    (= sol au repos). Pour rendre ces effets visibles il faut implementer
    l’AnimBrightnessSystem (phase B) qui re-calcule les vertex colors chaque
    ~5 ticks.
  • Le flicker des lampes suit la meme logique : invisible sans phase B.
  • Les eventuels halos d’explosions et flashs de tirs sont en phase D
    (encore plus tard).

La phase A actuelle ne fait briller que ce qui a Lb ≠ 0 au binaire (= les
lampes statiques toujours allumees, les zones intentionnellement sombres,
etc.). C’est la base.

Laisser un commentaire

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