Obligement - L'Amiga au maximum

Jeudi 22 février 2024 - 21:08  

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 68k - affichage de BOB avec le Blitter
(Article écrit par François Fleuret et extrait de Génération 4 - juin 1989)


Toujours dans le cadre de la programmation de démos, après le fameux article sur les sprites nous allons voir comment afficher à l'écran des BOB comme ceux de la démo de D.O.C ou bien de la XXX International Demo (qui ne sont pas des sprites matériels, contrairement à ce que suggèrent les auteurs dans leur texte défilant).

Eh, BOB !

Avant tout, il faut bien comprendre ce qu'est un BOB. Comme son nom l'indique (BOB = Blitter OBject), le BOB est un petit motif affiché grâce au Blitter dans la mémoire vidéo de l'Amiga. Comme les sprites, les BOB permettent d'afficher de petits objets mobiles (tels que les démons dans la démo de D.O.C) d'une manière assez rapide pour pouvoir en afficher un nombre conséquent. Il faut tout de même bien différencier les sprites des BOB car ils sont fondamentalement différents d'un point de vue technique : si les BOB sont affichés à l'écran par l'intermédiaire de la mémoire vidéo, les sprites, eux, sont rajoutés par-dessus le plan par le processeur vidéo et sont donc totalement indépendants. Cela implique deux choses pour les BOB :
  • D'énormes contraintes, car si un BOB doit se déplacer, il faudra effacer sa précédente position (ce qui devient réellement compliqué lorsque le BOB est sur un décor et encore plus si plusieurs BOB se superposent).
  • Une plus grande souplesse d'utilisation aussi bien au niveau de la taille que du nombre de couleurs disponibles.
Donc, en réalité, l'affichage d'un BOB est une copie de données par le Blitter dans la mémoire vidéo (plan de bits). La conception d'une routine de BOB revient donc à déterminer tous les paramètres de la copie à envoyer au Blitter pour afficher le BOB que l'on veut, où l'on veut, à l'écran. Les paramètres qui doivent être fournis sont nombreux :
  • Adresses des sources A, B et C de la copie.
  • Adresse de la destination D de la copie.
  • Modulos (sources et destination).
  • Opération logique.
  • Masques des bouts sur la source A.
  • Décalage de A et/ou B.
  • Taille du transfert.
Le Blitter permet de transférer des données d'une adresse à une autre adresse, en faisant même, si on le lui demande, une opération logique entre ses trois sources. Mais on en arrive vite à se demander comment on peut afficher un BOB à l'abscisse que l'on veut étant donné que les adresses doivent être paires et que donc le transfert se fera avec une précision horizontale de 16 points...

Pour remédier à ce problème, les géniaux concepteurs du Blitter ont intégré un système de "barillet" qui permet de faire subir à la source une rotation pour avoir une précision d'un pixel lors de l'affichage. Ce décalage se fait comme dans un barillet, ce qui signifie que ce qui sort sur la droite du bloc de données revient sur la gauche. Le problème avec ce barillet est qu'il faut avoir la place pour faire le décalage, cela oblige donc le programmeur à prendre une image qui fait 16 points de plus horizontalement, les 16 points de droite ne contenant pas de donnée serviront à recevoir la partie décalée qui sort à droite.

Notre routine

La routine que nous allons faire se limite à afficher des BOB 32.32 en 8 couleurs dans une image de n'importe quelle largeur. On connaît au départ X, Y (coordonnées du BOB à afficher), l'adresse de l'image 32x32 du BOB (prise dans une grande image) et la largeur des images (plans de bits et grande image où l'on prend l'image du BOB). Ici, l'écran est en 320x256 en 8 couleurs et l'image où se trouve le BOB est elle aussi en 320x256 en 8 couleurs mais elle n'est pas au format IFF, il faut donc la convertir avec le petit programme en BASIC fourni plus bas.

Notre routine va traiter séparément les trois plans de l'image (bien que cette méthode ne soit pas la meilleure pour ce qui est de la vitesse, comme vous pourrez le lire plus bas). On va donc faire au début les initialisations qui ne dépendent pas des adresses de départ et d'arrivée du transfert puis, pour chacun des trois transferts, on calculera les adresses.

On cherche donc au départ les paramètres qui sont toujours les mêmes. Il s'agit de l'opération logique, des masques de A, des modulos et du décalage. L'opération logique est un calcul booléen opéré par le Blitter entre ses trois sources afin d'obtenir la destination. L'utilité de ce système est grande : imaginons que l'on veuille recopier un BOB qui représente une balle sur un fond qui contient un décor. Comme l'image du BOB n'est pas carrée, il y aura autour de lui une zone noire copiée en même temps que l'image de la balle (car le Blitter ne fait que des transferts carrés) ce qui est relativement laid, il faut le dire. Pour éviter cela, la fonction logique permet de tenir compte du fond. Par exemple, si la source A pointe sur l'image et la B sur le fond, on pourra mettre D=A or B et dans ce cas le Blitter viendra rajouter, avec un OU logique, A sur le décor. Dans notre cas, il y a trois plans de bits à traiter, il faut donc que pour chaque point du BOB, si sa couleur est différente de 0, on la recopie dans les plans de bits. On va donc constituer ce que l'on appelle un masque. Chaque bit de ce masque représente un point. Si ce bit est à 0, cela signifie que le BOB est transparent à cet endroit-là (couleur 0), s'il est à 1, cela signifie que le BOB possède une couleur différente de 0 à ce point-là.

Pour l'affichage, on utilisera les trois sources A, B, et C en faisant pointer B sur l'image, A sur le masque et C sur le décor. On utilise A comme masque car cette source possède elle-même des masques qui permettent de supprimer les 16 points les plus à droite du BOB afin de vider la zone où va se faire le décalage. On fera alors :

D=(B and A) or (C and not A)

Le "and not" permet d'effacer le décor là où il y a un point du BOB. Le "or" copie le BOB dans le plan de bits, et enfin le premier "and" permet de ne pas afficher les données parasites qui se trouvent transférées avec le BOB.

Mais le Blitter ne peut utiliser l'opération sous cette forme. Il faut l'arranger avant de la programmer (pour plus de précisions, voir le Hardware Manual page 171 ou La Bible De L'Amiga page 195) en utilisant l'algèbre booléenne (on notera l'opération "not" en écrivant les lettres en minuscules, l'opération "and" étant représentée comme une multiplication et le "or" comme une addition) :

D=(B*A)-F(C*a)
D=BA+Ca
D=BA(C+c)+Ca(B+b)
D=BAC+BAc+CaB+Cab
D=ABC+ABc+aBC+abC

Cette opération correspond à la valeur "$CA" pour les huit bits de poid faible de BLTCON0.

Comme vous pouvez vous en douter, l'image des masques s'obtient très facilement en faisant un "or" logique entre les trois plans de l'image des BOB. Si un des bits est différent de 0 (et donc la couleur du point correspondant différente de 0), alors le masque contiendra un 1.

Pour les modulos de la destination, il suffit de calculer la largeur en octets de l'image affichée moins la largeur en octets de l'image transférée pour le BOB ; mais on a vu plus haut que l'on était obligé de prendre une image plus large de 16 points afin d'avoir de la place pour faire le décalage. Comme notre BOB a 32 points de large et que l'on transfère 16 points de plus, on transfèrera finalement 48 points soit six octets de large. Le modulo de la destination est donc :

LARGEUR_IMAGE-6

C'est exactement la même chose pour les sources.

Pour les masques des bouts des lignes sur A, on veut effacer les 16 points de droite (car ce sont des données non initialisées que l'on prend pour pouvoir faire le décalage, sans savoir à quoi elles correspondent) et garder les 16 points à gauche, donc le masque sera 0 pour la droite et $ffff pour la gauche.

Pour le décalage de B et de A (il faut aussi décaler le masque car les opérations logiques se font après le barillet) il est toujours le même puisque l'abscisse reste identique pour les trois transferts. On obtient assez rapidement ce décalage en faisant X and 15 (on prend les 15 bits de poids faible de X).

Enfin, pour la taille du transfert, c'est toujours 32 lignes de haut et 48 points (trois mots de large), ce qui donne comme valeur 32x64+3 pour BLTSIZE.

Maintenant que l'on possède les paramètres constants pour les trois transferts, il reste à trouver ceux qui sont particuliers à chacun d'entre eux : les adresses. Celles-ci s'obtiennent à partir de X, Y et l'adresse de base des plans des bits et de l'image où se trouve l'image du BOB. Pour calculer l'adresse relative du transfert dans les plans de bits, on fait simplement Y*40 (car on a 40 octets par ligne) + (X/8) and $fffe. Le "X/8" fournit l'adresse dans la ligne et le "and $fffe" permet d'obtenir une adresse paire (car le Blitter ne fait ses transferts qu'avec une précision d'un mot, pas d'un octet). Ensuite, pour chacun des trois transferts, on ajoute aux adresses la taille d'un plan de bits (aussi bien pour la mémoire vidéo que pour l'image des BOB). Pour faire fonctionner notre belle routine de BOB, nous allons mettre autour un petit programme qui permet d'afficher un BOB en cliquant avec la souris, pour cela, on prend les coordonnées X et Y de la souris (voir précédent numéro pour des explications limpides et exhaustives) et on affiche un BOB à cet endroit-là si la touche droite est enfoncée.

Assembleur
Assembleur
Assembleur
Assembleur
Assembleur

Pour pouvoir utiliser cette fantastique routine dans vos propres programmes, il ne faut pas oublier de placer également la routine PREPARE_MASQUES qui construit la table des masques des BOB. Il suffit, pour la mettre en oeuvre, de placer les images des BOB au label BITMAP et d'appeler la routine au début du programme. Pour la routine de BOB elle-même (DRAW_BOB), il faut lui passer plusieurs paramètres dans les registres (voir les commentaires du listing).

Programme de conversion d'images IFF

Voici à présent le petit programme en BASIC pour préparer l'image IFF (320x256 en 8 couleurs non compactée) qui contient le dessin du BOB (en haut à gauche 32x32). Ce programme a déjà été donné dans un précédent numéro mais enfin bon, comme il est court et que vous n'avez peut-être pas le numéro en question, le revoilà. Il prend une image 320x256 en 8 couleurs IFF non-compactée et la met en format plan de bits plus simple à utiliser pour les programmeurs (les plans de bits se suivent et la palette est au format de la palette d'Agnes).

BASIC

Comme je le disais au début, pour faire un affichage de BOB parfait, il faut faire comme les programmeurs de D.O.C, c'est-à-dire transférer tous les plans de bits en un seul transfert. C'est possible en prenant un autre format de mémoire vidéo et pour les images des BOB et en répétant trois fois chaque masque. Le format de la mémoire vidéo doit être le même que le format IFF : les lignes se succèdent (et non pas les plans de bits), en faisant cela (il suffit de mettre un modulo de 80 octets pour le plan et de faire commencer les pointeurs vidéo à des adresses décalées de 40 octets les unes par rapport aux autres) et en faisant la même chose au moment du transfert Blitter avec les images des BOB et les masques (avec des modulos de 0 octet pour la source et de 34 pour la destination) on peut copier les trois plans de bits en un seul transfert. Mais il faut que les masques soit répétés trois fois puisque l'on ne peut pas réutiliser le même masque pour les trois plans.

Ce n'est pas très clair mais je vous donnerai peut-être une routine utilisant ce système un de ces jours. Vous pouvez maintenant rajouter des démons partout dans vos démos, bon travail.


[Retour en haut] / [Retour aux articles]