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 - affichage 256 couleurs AGA
(Article écrit par Lionel Guillang et extrait d'Amiga News - janvier 1994)
|
|
Chose promise, chose due : voici de quoi en faire voir de toutes les couleurs à votre Amiga AGA,
puisque nous allons nous pencher ce mois-ci sur les modes "True Color", le HAM nécessitant un
article à lui tout seul. Allez, c'est parti...
True Color, késako ?
Derrière ce terme un peu savant que tous les graphistes connaissent bien, se cache en
fait un concept très simple : à chaque couleur disponible dans la palette correspond un registre couleur.
Le jeu de composants AGA autorisant une profondeur maximale de 8 plans, le nombre maximum de
vraies couleurs est donc 2^8, soit 256.
Les registres couleurs
L'adressage des 256 registres de couleurs se fait sur
8 tranches de 32 registres chacune, à partir du registre
COLOR ($0180). Ce n'est pas vraiment pratique, mais compatibilité oblige...
On code le numéro de la tranche à laquelle on désire accéder dans
les bits 13 à 15 du registre BPLCON3 ($0106). Contrairement au
découpage quartets de poids fort/quartets de poids faible des composantes
RGB (Cf. cet article),
l'ordre dans lequel on accède aux différentes tranches n'a pas d'importance.
La bitmap
C'est maintenant que les choses se corsent un peu : il est en effet nécessaire
de bien comprendre l'architecture du coprocesseur vidéo pour assimiler les nouveautés.
Dans l'ancien jeu de composants, les données vidéo étaient véhiculées,
via DMA, sous forme de mots (16 bits). Résultat : les pointeurs des plans de bits devaient
donc être pairs pour être "fetchés" correctement. En AGA, le principe reste le même,
mais devient plus flexible ; on peut désormais sélectionner
quatre modes différents : le mode compatibilité qui émule les anciens
jeux de composants (transferts 16 bits), le mode "burst 1", aussi appelé
mode 2X, qui transfère les données sur 32 bits, le mode "double burst 1"
qui transfère sur deux fois 16 bits (?), et enfin le mode "burst 2",
ou 4X, qui transfère sur 64 bits. Vous l'avez compris, le plus performant
est bien évidemment le mode 4X. La sélection du "fetching mode"
se fait grâce aux bit 0 et 1 du registre FMODE ($01FC) :
Bit 1 0 Mode
--------------------------------
0 0 normal 16 bits
0 1 normal 32 bits
1 0 double 16 bits (32 bits)
1 1 double 32 bits (64 bits)
|
Seulement, cela amène aussi des contraintes d'alignement des bitmaps :
en mode 2X, les pointeurs de plans de bits doivent être des multiples de
4 (32 bits), et en mode 4X des multiples de 8 (64 bits), pour être "fetchés"
correctement. De la même façon, la largeur des plans de bits doit respecter
ces alignements : on ne peut pas, par exemple, créer un vrai écran de 352
pixels de large (sans modulos) en mode 4X !
Toujours pour la même raison, les valeurs à donner aux registres DDFSTRT
et DDFSTOP varient en fonction du "fetching mode", et leur précision diminue
au fur et à mesure que la largeur de la bande augmente (16 pixels près en
mode ECS, 32 en 2X et 64 en 4X). Attention, cela peut induire des
erreurs : par exemple, en mode 4X, on peut initialiser DDFSTRT et DDFSTOP
respectivement à $28 et $a8, ou bien à $38 et $a0.
On obtiendra dans les deux cas, en apparence, un écran de 320 de large
sans aucun décalage des lignes, mais dans le premier cas celles-ci seront
"fetchées" inutilement plus tôt, nécessitant quelques cycles supplémentaires
d'où disparition d'un ou plusieurs sprites, ralentissement du Blitter, etc.
En règle générale, il faudra mettre la valeur la plus grande possible dans
DDFSTRT et la plus petite possible dans DDFSTOP : même si votre affichage
semble correct du premier coup, faites d'autres essais !
En mode 4X, seules deux positions de fetching sont possibles de part et
d'autre de l'écran : overscan (suraffichage) ou non : il semblerait donc qu'il
ne soit pas possible de programmer un défilement Copper en suraffichage
dans ce mode (devinez pourquoi !) : ce n'est pas bien ça !
Voici des valeurs standard pour des écrans non suraffichage centrés :
LoRes HiRes S-HiRes
Mode ECS $38-$d0 $3c-&d0 &3e-&d2
Mode 2X $38-&c8 $38-&d0 $3c-&d0
Mode 4X &38-&a0 $38-&c0 $38-&d0
|
N'oubliez pas que le pas diminue lorsque la résolution augmente (8 en LoRes,
4 en HiRes et 2 en Super HiRes !).
Autre nouveauté dûe aux nouveaux alignements : le registre BPLCON1
($0102) a été étendu de façon à pouvoir gérer des décalages de 0 à 255,
à 35 nanosecondes près, soit un pixel en Super HiRes (contre 0 à 15 et 140 ns
sous ECS). Les quatre bits supplémentaires sont les bits 11-10/9-8
pour le premier champ de jeu et 15-14/13-12 pour le second. Par exemple
un décalage de 56 pixels LoRes sur les deux champs de jeu sera codé en
&CC88.
Voyons maintenant comment définir la profondeur et la résolution horizontale : l'initialisation
de la profondeur se faisait auparavant grâce aux bits 12 à 14 du registre BPLCON0
($0100). Cela n'a pas changé en AGA, à un détail près : 3 bits ne permettant de coder
que 8 valeurs différentes (0 à 7), il faut avoir recours au bit 4 pour commuter
en mode 8 plans de bits. Lorsqu'il est mis, les trois autres sont ignorés,
inutile d'essayer d'activer 15 plans de bits !
En ce qui concerne les résolutions horizontales standard, pas grand-chose de neuf :
leur initialisation se fait aussi grâce au registre RPLCON0 : par défaut on est en LoRes,
le bit 15 active la HiRes, le bit 6 la Super HiRes. Pour l'anecdote, sachez qu'il existe
une quatrième résolution horizontale possible, désignée par le doux nom de UHRES,
c'est-à-dire ultra haute résolution ! Ne me demandez pas à quoi elle correspond,
je ne suis pas encore parvenu à l'activer de façon satisfaisante : tout ce que je
peux dire pour l'instant, c'est qu'il faut mettre à un le bit UHRES (7) dans BPLCON0
($0100) mais apparemment il y a d'autres registres à initialiser (BEAMCON0
par exemple) (NDLR : la UHRES affiche un seul plan en 1024x1024 avec un seul sprite
de disponible).
Autre nouveauté : les registres fenêtre (DIWSTRT et DIWSTOP) ont eux aussi été
étendus : comme tous leurs bits étaient déjà affectés, un nouveau registre est
apparu : DIWHIGH (&01E4). En voici la description :
Extension a DIWSTRT :
Bits 05 04 03 02 01 00
H10 H1 H0 V10 V9 V8
|
Extension a DIWSTOP :
Bits 13 12 11 10 09 08
H1O H1 H0 V10 V9 V8
|
Les autres bits sont pour l'instant inutilisés et doivent donc être mis à 0. Les bits de position
horizontales ont été décalés de façon à pouvoir définir la fenêtre à 35 nanosecondes près :
l'ancien H0 est toujours H0 en LoRes (140 ns) mais devient H2 en Super HiRes ou H1
en HiRes (hum, c'est clair, non ?).
Et pour finir, les pointeurs de plans de bits : les quatre (2x2) supplémentaires nécessaires
à une profondeur de 8 ont été ajoutés à la suite des anciens registres :
ce qui donne $00F8 et &00FA pour le 7e plan, $00FC et &00FE pour le 8e.
Le programme
Le source que je vous propose ce mois-ci est un tantinet simplet,
mais il présente l'avantage de bien mettre en évidence la façon d'activer
un affichage 256 couleurs LoRes en mode 4X.
En résumé, il met en place un écran 320x256, dessine 256 rectangles de
couleurs différentes, et cycle les 16,7 millions de couleurs disponibles,
en AGA. Étant donné qu'il rafraîchit les 256 couleurs de la palette à
chaque VBL, soit 50 fois par seconde, il faudra un certain temps (un
peu plus de 20 minutes, faites le calcul) pour que le cycle complet
s'accomplisse devant vos petits yeux émerveillés !
Ah oui, j'allais oublier : cette fois encore, l'écran actif au moment
où vous lancerez le programme, doit être balayé à 50 Hz,
sous peine d'obtenir un affichage distordu.
Le mois prochain, un peu moins de couleurs mais un peu plus d'animation,
puisque nous aborderons les sprites AGA.
|
