Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - Tube-Intro (routine d'animation d'étoiles)
(Article écrit par Little Zeus et extrait d'Amiga News Tech - octobre 1989)
|
|
Après de longs mois de dur labeur, nous avons enfin, dans le dernier numéro,
achevé la Tube-Intro. Néanmoins, et ce dans un désir de perfection, implantons dans le fond un multidéfilement
d'étoiles différentiel, autrement dit, en arrière-plan de notre défilement de caractères en forme de tube et
de notre divin logo perpétuellement animé. Mais attention, ce défilement se fait sur plusieurs plans de vitesses
différentes.
Rappel sur le sprite
Cessons de vous mettre l'eau à la bouche et commençons. Rappelons quelque peu le début de théorie que nous nous
avions vu au sujet des sprites dans le précédent numéro. Le sprite est un élément graphique d'une largeur maximale
de 16 pixels et d'une hauteur de votre choix. Le nombre de canaux sprites est de huit. Habituellement,
les sprites comportent trois couleurs ; cependant, en combinant les sprites deux à deux, nous pouvons obtenir
des sprites de quinze couleurs.
Les couleurs des sprites correspondent aux registres couleurs allant du 16 au 31. Il faut tout de
même tenir compte du fait que deux sprites successifs possèdent les mêmes couleurs. Nous avons alors 16 couleurs
à répartir sur quatre fois deux sprites. Il en découle qu'à chaque paire de sprites, correspondent quatre
couleurs dont la première, en dépit de la couleur préprogrammée dans la palette, correspond au transparent.
Pour afficher un sprite, il faut préalablement définir une liste le concernant. Celle-ci se divise en trois
parties :
- Une première définissant les coordonnées de début et de fin du lieu sur l'écran où doit s'afficher
le sprite.
- Une deuxième contenant ses données bitmap.
- Et enfin une dernière composée d'un long mot nul, qui spécifie la fin de la liste sprite.
Nous passerons outre les détails de ces parties. Pour de plus amples informations, il vous suffira de vous reporter
au numéro précédent. Notez que lorsque nous parlons de sprite, parfois, nous faisons d'une certaine manière
un abus de langage. Il est dit que l'Amiga ne possède que huit sprites, il serait plus juste de dire que
ce dernier possède huit canaux DMA sprites. Cependant, par cause de simplification, on parle de sprite autant
pour canal DMA sprite que pour sprite. D'ailleurs, nous aurions été bien ennuyés de n'avoir que huit étoiles à
l'écran...
Enfin, pour activer les canaux DMA sprites, il suffit de "poker" les adresses de bases respectives de chaque
liste sprite dans les registres SPRXPTHL. De plus, il ne faut absolument pas oublier de lancer le DMA sprite
par un MOVE.W #$8220,$DFF096.
Les sprites en mouvement
Le secret permettant l'animation des sprites n'en est certainement plus un pour vous. Nous ne doutons
pas que vous avez déjà pensé à changer la valeur des deux mots de contrôle, de manière à donner de
nouvelles coordonnées au sprite et de ce fait de le bouger. Mais soyons tout de même prudent, car
des pièges s'annoncent.
C'est-à-dire qu'il ne faut absolument pas changer ces valeurs à tout vent.
Pensez au cas dans lequel vous avez uniquement changé le premier mot de contrôle et malheureusement, à
ce même instant, le DMA lit les deux mots de contrôle. La valeur lue est par conséquent erronée, et ce,
pour la simple et bonne raison que le premier mot appartient aux nouvelles coordonnées alors que le
second appartient aux anciennes coordonnées.
Il n'y a néanmoins pas lieu de s'inquiéter.
Pour éviter de tels désagréments, il suffit de modifier les valeurs pendant que le Raster balaie l'écran
invisible. C'est-à-dire la partie supérieure de votre moniteur. On parle aussi de "temps mort vertical".
Priorités des champs de jeu par rapport aux sprites
Parlons d'un sujet qui a une incidence directe sur notre routine. Il s'agit des priorités des sprites par
rapport aux champs de jeu ("playfields") et celles qui existent au sein même des sprites, c'est-à-dire quel sprite se placera
devant quel autre. Nous ne nous éterniserons pas sur cette question des priorités, nous ferons simplement
un survol des différents bits du registre concerné, en l'occurrence BPLCON2. Celui-ci est situé au
décalage $104 et compte 16 bits :
Bit
numéro 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
A A A A A A A A A A B B B C C C
|
"A" indique les bits inutilisés, "B" les bits correspondant à la position du champ de jeu composé
des plans de bits impairs, par rapport aux quatre paires de sprites, et "C", idem pour la position
du champ de jeu composé des plans de bits pairs.
Nous remarquons que nous avons à notre disposition deux fois trois bits, soit deux fois
cinq possibilités. Voici sous forme d'un petit tableau ce à quoi correspond chaque chiffre.
Chiffre |
Priorité d'affichage |
00 |
Champ de jeu Sprites 0&1 Sprites 2&3 Sprites 4&5 Sprites 6&7 |
01 |
Sprites 0&1 Champ de jeu Sprites 2&3 Sprites 4&5 Sprites 6&7 |
02 |
Sprites 0&1 Sprites 0&1 Champ de jeu Sprites 4&5 Sprites 6&7 |
03 |
Sprites 0&1 Sprites 0&1 Sprites 2&3 Champ de jeu Sprites 6&7 |
04 |
Sprites 0&1 Sprites 0&1 Sprites 2&3 Sprites 4&5 Champ de jeu |
Ainsi que vous pouvez le constater, plus le chiffre s'accroît, plus la priorité du champ de jeu est
faible. Le tableau précédent peut s'appliquer de manière analogue aux deux champs de jeu. Ensuite,
il vous revient de combiner à bon escient les bits B et C.
Principe de la routine
Après ce complément de théorie sur les sprites, nous pouvons assurément aborder le principe
de notre routine. D'une manière assez astucieuse, nous allons animer des sprites d'étoiles
de visses et de couleurs différentes en n'utilisant qu'un seul canal sprite DMA. Tout
d'abord, nous devons nécessairement insérer dans le début de la liste Copper (rappelez-vous
ce qui a été précédemment dit au sujet du "temps mort") la ligne suivante :
Sprite0: dc.w $0120.0000,$0122,0000
|
L'explication de cette ligne est simple : il s'agit de profiter du Copper pour repointer le
canal DMA sprite numéro 1 à chaque balayage. Quant à l'instruction "SWAP" que vous
pouvez remarquer dans les premières lignes de la routine, elle permet indirectement de "poker"
respectivement dans la liste Copper les poids forts et faibles du début de la liste sprite.
Et donc par répercussion, de vectoriser le canal DMA sprite numéro 1 sur la liste sprite.
En effet, SWAP inverse les mots de poids faible et de poids fort d'un long mot. Par exemple, en
admettant que d0 contienne initialement $12345678 à la suite d'un "SWAP d0". d0 contient $5781234.
Il convient de préciser deux petites subtilités : la première correspond à l'utilisation du PC
(pointeur de pile), ce qui permet une économie de mémoire, à fortiori une plus grande rapidité d'exécution. Nous
reviendrons dans un prochain numéro sur ce mode d'adressage ; sachez cependant que pour la routine
ci-présente, nous aurions pu tout aussi bien se passer du PC.
La deuxième subtilité concerne les lignes sur lesquelles nous animerons les étoiles ;
celles-ci passeront uniquement sur les lignes paires. Pourquoi ? Pour deux raisons : le
canal DMA ne pouvant lire que deux mots par ligne, et nos étoiles ne faisant qu'une ligne de haut,
le DMA doit, après chaque étoile, connaître les coordonnées de la suivante.
Cependant, ces coordonnées prennent deux mots, il en résulte donc que le DMA nécessite une ligne sur
deux pour lire les coordonnées et ne peut afficher les étoiles qu'une ligne sur deux.
Cette raison est suffisante pour ne pas s'encombrer d'étoiles à chaque ligne. De plus, le bit
de poids le plus faible de la position horizontale du sprite se trouvant dans le second mot,
contrairement aux autres bits qui se trouvent dans le premier, il serait bien laborieux
d'incrémenter ce bit.
Notez pourtant que si vous souhaitez absolument des étoiles à chaque ligne, vous devez alors utiliser
au moins deux canaux DMA (un pour les lignes paires et l'autre pour les lignes impaires).
La raison de "retour à la case départ" de chaque étoile s'explique par le fait que lorsque le compteur
de chacune d'elle dépasse l'abscisse 512, ce compteur étant sur 9 bits, la valeur suivante est 0.
Il apparaît évident que nous aurons un temps pendant lequel chaque étoile n'apparaîtra pas à
l'écran, c'est-à-dire sur les abscisses allant de la limite gauche de l'écran à l'abscisse 512.
Avant de passer à la suite, précisons l'utilisation de l'instruction LSL. Son rôle est simple, elle
décale vers la gauche le contenu d'un octet si elle est suivie de .B. d'un mot pour .W.
ou enfin d'un mot long pour .L. Ce décalage se fait du nombre de bits specifié à la suite de
l'instruction. Par exemple, LSL.W #2.X décale le contenu de "X" de deux bits vers
la gauche. Comme vous avez certainement pu le remarquer, de par le système binaire, un décalage vers
la gauche d'un bit correspond à une multiplication par 2. Par conséquent, l'objet de l'instruction
au sein du programme est de multiplier par 2 puissance 2, soit 4, la valeur de la vitesse, ce qui
donne un nombre permettant d'accéder aux données des couleurs.
Un dernier petit détail concernant le dépassement de la ligne 255 : effectivement, sur les huit
bits de la position verticale du premier mot de contrôle, nous ne pouvons pas excéder la
ligne 255. Heureusement, le second bit du deuxième mot de contrôle nous sert de neuvième bit ;
il en émane que nous pouvons animer les sprites sur 512 lignes. Cependant, le bas de l'écran
s'arrêtant à la 296e ligne, il nous suffit de faire un test astreignant les étoiles à ne pas
dépasser celle-ci.
Sur ce, je vous quitte et vous donne rendez-vous dans le prochain numéro avec du changement :
nous allons explorer le fin fond du matériel de la machine ou de l'unité de disquette au
moyen d'un antivirus ultra-performant.
|