Constat utilisateur
Les niveaux paraissent « applati » (perception confirmee par le ratio
largeur/hauteur calcule sur zone 0 de LEVEL_A : 26 JME x 4 JME = ratio 6.5x,
couloir tres etire horizontalement) et certains murs montrent ce qui semble
etre 3 textures stackees alors que l’original n’en montre qu’une seule
avec juste le haut coupe par la difference de hauteur.
Diagnostic
Calcul direct depuis le JSON {@code level_A.json} :
- Wall {@code L=2 -> R=4} dans zone 0 : points (-768, 512) et (-512, 256)
- Distance euclidienne = sqrt(256^2 + 256^2) = ~362 amiga units
- Texture brownspeakers tile = 128 px
- {@code numRepeats = ceil(362 / 128) = 3} -> la texture est tilee 3x
horizontalement, donnant l’illusion de 3 textures distinctes alors que
c’est la meme.
L’extent de zone 0 (calcule sur les 15 pointIds) :
– X : -1152 a -320 = 832 amiga -> 26 JME (avec SCALE=32)
– Z : -320 a 640 = 960 amiga -> 30 JME
– Y : 128 amiga -> 4 JME (utilisateur confirme : OK)
L’utilisateur attend une zone proportionnee (ratio L/H ~ 2-3x). Hypothese
de travail : les coords XZ sortant du parser sont 3x trop grandes.
Modification (test isole, reversible)
tools/LevelSceneBuilder.java
– Ajout d’une constante XZ_DIV controlee par la system property
-Dab3d2.xzDiv=N (defaut 1.0 = no-op, comportement inchange).
– {@code parsePts}, {@code parseEdges}, {@code parseEdgesFull} appliquent
desormais Math.round(value / XZ_DIV) sur chaque coord X/Z (et
dx/dz pour {@code parseEdgesFull}).
– Toute la geometrie horizontale (walls, sols, plafonds, portes, lifts,
zone polygons utilises par {@code ZoneTracker}) passe par ces 3 methodes
et est donc retrecie par XZ_DIV.
Limitation connue
Les spawns (player1, player2, items, aliens, control points) ne sont PAS
scaled. Avec -Dab3d2.xzDiv=3, le joueur apparait hors des zones et les
items/aliens sont mal places. C’est volontaire : le test sert a valider
visuellement l’hypothese d’echelle avant de patcher l’ensemble du pipeline.
Comment tester
Le facteur XZ_DIV s’applique au moment du build des scènes (.j3o). Une
fois bake, le runtime n’a pas besoin de la propriete.
./gradlew buildScenes -Dab3d2.xzDiv=3 # rebuild .j3o avec geom XZ retrecie /3
./gradlew run # joue (la geom est figee dans les .j3o)
Pour revenir a l’etat normal :
./gradlew buildScenes # XZ_DIV par defaut = 1, geom inchangee
Note : la system property -Dab3d2.* est forwardee au child JVM par le
task buildScenes via le bloc ajoute en session 131. Pas besoin de
gradle.properties pour ce test ponctuel ; le defaut Java (1.0) couvre le
cas no-op.
Si le rendu correspond visuellement a l’original WinUAE (mur unique avec
seul le haut coupe, ratio largeur/hauteur normal), l’hypothese est validee
et on pourra chercher la cause profonde dans le pipeline (ASM source ou
LevelBinaryParser) et appliquer le fix proprement (incl. spawns).