Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 13:18  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


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.

assembleur
assembleur
assembleur


[Retour en haut] / [Retour aux articles] [Article précédent]