DEATH (./114) :
Chose amusante aussi, si on défini YPOS à une valeur inférieur à VDB, l'image s'affiche quand même mais comme si YPOS était égale à VDB
D'ailleurs du coup, comment fait on si on veut scroller une image vers le haut vu qu'il n'y a pas de valeur négative de YPOS ?

Dernière chose, si je défini le 2ème branch objet (celui qui détecte si VC>YPOS) plus grand que VDB, ça décale tout l'affichage d'autant !

OSCOUR

Dans le cas ou VDE = FFFF, l'OP est démarré à chaque ligne.
Pour éviter la surcharge et permettre l'affichage des bitmaps à partir de la bonne ligne il faut définir correctement les 2 branches de début en conséquence (en gros pour faire l'équivalent VDB/VDE).

Dans le cas ou VDE /= FFFF, l'OP est démarré à chaque ligne entre VDB et VDE, mais il y a potentiellement des bugs d'affichages (1er et/ou dernière lignes corrompu)


Dans tous les cas, la ligne courante de la bitmap est celle pointée par DATA.
Donc si tu mets un branch obj avant ton bitmap du genre :
branch VC > 511, .stop branch VC < 100, .stop bitmap YPOS= 28, DATA=$10000, HEIGHT=10 .stop: stopl'Obj bitmap ne sera pas mis à jour avant la ligne 100, donc quand la bitmap sera parsé à partir de cette ligne, pour l'OP la bitmap sera toujours valide, ie : YPOS <= VC && HEIGHT > 0.
Du coup dans cette exemple, la bitmap sera affichée sur les 10 prochaines lignes. (à chaque ligne traitée, l'OP va mettre à jour DATA & HEIGHT)

C'est le même principe si l'obj n'est pas parsé en mettant un YPOS < VDB avec un VDE /= FFFF.


Pour scroller vers le haut avec YPOS < VDB, il faut en fait avoir YPOS = VDB et mettre à jour en conséquence HEIGHT & DATA.