Obligement - L'Amiga au maximum

Jeudi 28 mars 2024 - 11:40  

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 - Les défilements avec le Blitter
(Article écrit par Frédéric Mazué et extrait d'Amiga News Tech - mai 1990)


Commençons par récapituler brièvement ce que nous savons déjà faire avec notre fameux Blitter :
  • Nous savons transférer des données, ce qui nous a permis de placer une image dans un plan de bits.
  • Nous savons transférer des données selon certaines conditions grâce à l'utilisation des Minterms pour, par exemple, éviter des recouvrements d'images.
  • Nous savons amputer une image à ses extrémités. Nous verrons plus loin que ceci est très utile.
  • Nous savons modifier une image en même temps que nous la copions grâce aux masques.
Mais les plus curieux d'entre vous auront peut-être essayé, en modifiant les listings que je vous ai déjà donnés, de placer l'image à n'importe quelle position sur l'écran. Quelque chose me dit que vous n'y êtes pas arrivés !

Le problème

En effet, s'il est très simple de positionner une image sur l'écran dans le sens de la hauteur, il suffit de charger le registre BLTDPTH avec les valeurs appropriées pour pointer sur la ligne de son choix, il ne nous est pour l'instant pas possible de choisir la position horizontale de l'image au point près. Tout simplement parce que le Blitter travaille avec des mots et que BLTDPTH pointera dans le plan de bits cible sur l'adresse d'un mot. Un mot contenant 16 bits allumant chacun un point, la position horizontale de l'image ne peut être pour l'instant choisie que tout les 16 points.

La solution

Les plus attentifs auront remarqué que les registres BLTCON0 et BLTCON1 ont jusqu'à maintenant été chargés de cette façon :

move.w #%0000xxxxxxxxxxxx,BLTCON0
move.w #%0000xxxxxxxxxxxx,BLTCON1

C'est-à-dire qu'à chaque fois les bits 12 à 15 étaient annulés dans les deux registres. Les quatre bits 12-15 de BLTCON0 concernent la source A. Les quatre bits 12-15 de BLTCON1 concernent la source B. La source C n'est pas utilisable pour les défilements horizontaux.

Les experts en binaire que vous êtes auront immédiatement compris que quatre bits permettent d'écrire toutes les valeurs de 0 à 15 (soit 16 valeurs).

A quoi servent ces quatre bits ? A faire décaler par le Blitter de la valeur décrite par ces quatre bits tous les bits de données d'une source. Cette opération est effectuée par le Blitter en même temps que le transfert de données sans aucun ralentissement.

Un exemple pour bien comprendre : voilà une zone de données A constituée de trois mots :

0001010111100100 1110000011010111 xxxxxxxxxxxxxxxx

Le registre BLTCON0 est chargé comme suit :

move.w #%0010xxxxxxxxxxxx,BLTCON0

"0010" en binaire vaut 2 en décimal, donc tous les bits seront décalés de deux "crans" sur la droite et le résultat dans la cible sera :

xx00010101111001 0011100000110101 11xxxxxxxxxxxxxx

On constate alors que les bits "xx" de gauche (ceci seulement pour le premier mot de l'image) contiendront ce qu'il y a déjà dans la zone cible. Si l'on suppose que l'exemple ci-dessus correspond à une image de deux mots et d'une ligne, on s'aperçoit puisque chaque bit allume un point que l'image entière est déplacée de deux points sur la droite. On comprend ainsi qu'il est possible de cette manière de placer une image à n'importe quelle position horizontale et donc de réaliser des défilements.

Mais attention au piège grossier ! Les bits de droite de chaque mot de donnée sont expulsés dans le mot de données d'adresse immédiatement supérieure. Pour faire défiler une image, il faut donc prévoir des zones "tampon", ce qui explique que dans le listing d'exemple l'image soit agrandie d'un mot nul pour chaque ligne (les valeurs modulos sont bien sûr modifiées en conséquence).

Sachant tout cela vous n'aurez aucune difficulté pour comprendre le premier listing d'exemple. Le programme est constitué de deux boucles imbriquées : une boucle pour faire défiler l'image sur tous les "points" d'un mot, et une boucle pour la position initiale de l'image avant défilement tous les 16 points.

assembleur
assembleur
assembleur
assembleur
Ce listing montre comment programmer le Blitter
pour obtenir un défilement horizontal


Remarquez la ligne (1) : move.w #$7fff,BLTAFWM(a0). Ainsi, le premier point de chaque ligne de l'image sera masqué. Ceci afin d'éviter que chaque déplacement de l'image ne laisse subsister une petite barre verticale.

Remarquez également un nouveau moyen de s'accaparer le Blitter : passer en mode superviseur. Comme en mode superviseur, l'Amiga n'est plus multitâche, seul notre programme accédera au Blitter. En plus, cela permet de ne pas être dérangé par les routines d'interruptions et de pouvoir tester le blanc vertical avec précision. On dit qu'on a le blanc vertical quand le rayon (raster) du tube cathodique de l'écran n'est pas visible. Il faut défiler l'image à ce moment afin d'éviter les saccades.

Plus vite !

Dans le listing, modifiez trois lignes comme suit :

(1) move.w #$3fff,BLTAFWM(a0)
(2) cmp.w #$e000,d7
(3) add.w #$2000,roll

...pour obtenir un défilement deux fois plus rapide.

Et enfin :

(1) move.w #$0fff,BLTAFWM(a0)
(2) cmp.w #$c000,d7
(3) add.w #$4000,roll

...pour obtenir un défilement quatre fois plus rapide.

Test de collision

Cela peut se faire grâce au test du bit 13 de DMACON. C'est le bit appelé BZERO. Quand le Blitter démarre BZERO est initialisé à 1. Quand le Blitter travaille, il le fait suivant les combinaisons logiques définies par les Minterms. Tant que les Minterms empêchent le Blitter de mettre un bit à 1 dans la zone cible, le bit BZERO reste à 1, dès que le Blitter met un bit à 1 dans la zone cible le bit BZERO est annulé et le reste jusqu'à la fin du travail du Blitter et cela quels que soient les résultats ultérieurs.

Il est maintenant possible d'examiner le deuxième listing. Ce programme est déjà une petite animation faite au Blitter !
  • Un écran à trois plans de bits est ouvert.
  • Puis une image appelée "cache" est installée dans le deuxième plan de bits.
  • Puis une image appelée "obstacle" est installée dans le troisième plan de bits.
Le but du programme est de faire défiler notre image maintenant familière dans le premier plan de bits en donnant l'impression de passer derrière le cache (Cf. article sur les combinaisons logiques) et en s'arrêtant à la "rencontre" de l'obstacle.

assembleur
assembleur
assembleur
assembleur
assembleur
Exemple de programmation du Blitter
pour obtenir un défilement horizontal avec test de collision


On ne veut pas que l'image mobile chevauche l'obstacle même d'un seul point. Il faut donc tester avant chaque déplacement s'il y aura collision. Pour cela, on effectue le déplacement à vide en bloquant le canal DMA D (voir initialisation de roll1). Le Blitter n'y voit que du feu et fait un transfert de données qui n'arrivera... nulle part. Mais on pourra savoir s'il y aurait eu collision en testant BZERO.

Regardez les Minterms de roll1. BLTDPTH pointe sur l'image mobile, BLTBPTH pointe sur une zone équivalente en taille et en position à l'image dans le 3e plan de bits. Les Minterms disent : transfert pour AB. Tant que l'image n'est pas arrivée sur l'obstacle, on n'a pas B donc le transfert ne peut se faire et BZERO reste à 1. Dès qu'on arrive sur l'obstacle, le transfert peut se faire (nulle part car DMA D est bloqué) et BZERO est annulé : la collision est détectée. Pour vérifier que tout se passe bien comme prévu, vous pouvez modifier dans le listing la position de l'obstacle. Mais pas trop à gauche tout de même sinon la collision serait détectée avant même de commencer...

Défilement vertical

Afin d'être complet, le listing 3 présente un défilement vertical. Rien de mystérieux. Il suffit d'initialiser convenablement BLTDPTH à chaque déplacement. Une petite astuce pour paresseux : l'image comporte une ligne de mots nuls en plus. Ainsi, l'image efface d'elle-même en se déplaçant la traînée qu'elle laisserait sans cette ligne de mots nuls.

assembleur
assembleur
assembleur
Ce listing montre comment programmer le Blitter
pour obtenir un défilement vertical


Je vous retrouve le mois prochain pour le remplissage de surfaces.


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