Session 132duodecimus (suite 7 audit) — Audit ASM animations d’arme

Decouvertes importantes

Apres lecture detaillee de :
– modules/player.s::plr_KeyboardControl (changement d’arme)
– newplayershoot.s::Plr1_Shot (tir)
– objdrawhires.s::draw_PolygonModel (rendu de l’arme)

1. Pas d’animation de « raise » (= levee de l’arme a la selection) dans
l’ASM original. Au changement d’arme, le code se contente de :

move.w  #0, ENT_NEXT_2+EntT_Timer1_w(a3)   ; reset timer
bsr     plr_ShowGunName                     ; affiche le nom

Aucune sequence d’animation specifique n’est jouee. L’arme apparait
directement avec son cycle d’anim continu normal.

2. Pas de plages de frames distinctes (idle/fire/reload) pour les armes.
MaxFrame est une variable globale jamais initialisee, juste lue dans
Plr1_GunFrame_w au tir. Le rendu ASM lit move.b 5(a0), d7 ; current
frame of animation directement — un seul flot continu de frames.

3. Le commentaire * Just for charles (animate automatically) dans
objdrawhires.s (ligne ~3015) montre qu’a un moment ils faisaient cycler
les frames automatiquement. Le code de cyclage est commente mais existe :

; add.w   #1,d5
; cmp.w   d6,d5
; blt.s   okless
; moveq   #0,d5
;okless:
; move.w  d5,8(a0)

Implications pour notre port

• Etape C « animation de raise » : annulee dans sa version « raise animation ».
  Si l’arme reste figee a la frame 0 c’est qu’on a bloque l’anim au chargement
  (stopAnimations() dans loadWeapon) ; il faudra peut-etre la re-activer.
• Code mort des plages (rangeMode etc.) : decision differee, pas urgent.
• « Bug du viseur sniper » rapporte par le user : a verifier en jeu.
  Si c’est du z-fighting, fixable par polygon offset. Si c’est juste l’anim
  continue qui parait etrange, c’est le comportement original.