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 : Programmer les modes graphiques AGA
(Article écrit par Yragael et Junkie et extrait d'Amiga News - novembre 1993)
|
|
Dans article sur l'AmigaOS 3.0, les nouvelles fonctions des
bibliothèques du système 3.0 étaient décrites. Dans la lignée, voici des descriptions
très "matérielles" pour programmer tous les nouveaux modes graphiques que nous offre le jeu de composants AGA.
Utilisation du mode super hires (super haute résolution)
Ce mode graphique permettant d'utiliser un écran de 1280 pixels de large existait déjà sur les Amiga
600 et 3000 (puces ECS). Bien entendu, il a été conservé sur les nouveaux Amiga. Pour déclencher ce mode
graphique, il suffit de fixer à 1 le bit 6 de BPLCON0 ($dff100).
Bit 6 de BPLCON0 : 1 -> Super Hires sélectionné
Tout ce qui suit est spécifique au nouveau jeu de composants AGA (ne concerne pas les Amiga 600 et 3000).
De 0 à 8 plans de bits
On peut utiliser jusqu'à 256 couleurs dans tous les modes de résolution.
Cela nécessite donc jusqu'à 8 plans de bits (2^8=256). De 0 à 7 plans de bits, rien n'a
changé par rapport à l'ECS : la sélection s'effectue grâce aux bits 14 à 12
de BPLCON0 ($dff100).
Pour accéder à 8 plans de bits, il suffira de fixer à 1 le bit 4 de ce même registre (BPLCON0).
Dans ce cas, les bits 14 à 12 ne seront pas pris en compte (il est tout de même conseillé
de les fixer à 0 afin de prévoir la compatibilité avec de futures machines).
Bit 4 de BPLCON0 : 1 -> 8 plans de bits sélectionnés
16 millions de couleurs
Les nouveaux Amiga ont une palette de 16 millions de couleurs. Elles sont donc
codées sur 24 bits. Pour assurer la compatibilité avec les anciennes machines, les
anciens registres de couleurs ont été conservés (registres 16 bits). En fait, ils
sont maintenant double : la même adresse permet d'accéder à deux registres différents :
- Un pour les quatre bits de poids forts de chaque composante RVB (ceux que
l'on utilisait sur les anciens Amiga).
- Un pour les quatre bits de poids faibles de chaque composante RVB.
Pour définir, si on veut accéder à l'un ou l'autre des registres, il suffit d'utiliser
le bit 9 de BPLCON3 (nouveau registre : &DFF106).
Bit 9 de BPLCON3 ($DFF006) :
0 -> bits de poids forts de la couleur
1 -> bits de poids faibles de la couleur
Ce bit est remis à 0 à chaque "vertical blank" (temps mort vertical). Exemple : mettre $00123456 dans la couleur0.
move.w #$0000,$DFF106
move.w #$0135,$DFF180
move.w #$0200,$DFF106
move.w #$0246,$DFF180
|
Si vous voulez travailler en couleurs 12 bits (4096 couleurs comme sur les anciens Amiga),
il vous suffira d'initialiser que le registre de poids forts des couleurs.
256 registres de couleurs
Comme précédemment, il n'existe pas 256 registres différents. Seuls les anciens 32
registres de couleurs existent. Le système est le même que pour les couleurs en 24
bits : un même registre permet d'accéder à 8 registres (doubles) différents de couleurs.
Le découpage des 256 couleurs se fait donc en 8 palettes de 32 couleurs chacune.
Pour accéder à un registre donné, il faut donc spécifier la palette à laquelle il appartient
à l'aide des bits 15 à 13 de BPLCON3 (&DFF106). Voici un tableau qui vous permettra de
définir facilement la palette à laquelle appartient un registre donné :
BPLCON3 : $DFF006
| bit 15 |
bit 14 |
bit 13 |
Palette sélectionnée |
| 0 |
0 |
0 |
Palette 0 (couleur 0 à 31) |
| 0 |
0 |
1 |
Palette 1 (couleur 32 à 63) |
| 0 |
1 |
0 |
Palette 2 (couleur 64 à 95) |
| 0 |
1 |
1 |
Palette 3 (couleur 96 à 127) |
| 1 |
0 |
0 |
Palette 4 (couleur 128 à 159) |
| 1 |
0 |
1 |
Palette 5 (couleur 160 à 191) |
| 1 |
1 |
0 |
Palette 6 (couleur 192 à 223) |
| 1 |
1 |
1 |
Palette 7 (couleur 224 à 255) |
Exemple : mettre $00123456 dans le registre de couleur 177.
Ce registre est en fait le 17e de la palette 5.
move.w #$A000,$DFF106
move.w #$0135,$DFF1A2
move.w #$A200,$DFF106
move.w #$0246,$DFF1A2
|
La commutation de palette (palette switch)
La commutation de palette permet d'inverser des blocs de registres dans
la palette lors de l'affichage : cette opération ne modifie aucunement la valeur des
registres de couleurs (l'inversion n'est que virtuelle). L'inversion s'effectue
de la manière suivante : échange des blocs 1 et 2, échange des blocs 3 et 4, etc.
Le contrôle de la taille des blocs à inverser se fait à l'aide des 8 bits de poids
fort du registre $DFF10C (que j'appellerai BPLCON4) :
BPLCON4 : $DFF10C
| Bit |
Fonction |
| 15 |
1 = commutation par blocs de 128 |
| 14 |
1 = commutation par blocs de 64 |
| 13 |
1 = commutation par blocs de 32 |
| 12 |
1 = commutation par blocs de 16 |
| 11 |
1 = commutation par blocs de 8 |
| 10 |
1 = commutation par blocs de 4 |
| 9 |
1 = commutation par blocs de 2 |
| 8 |
1 = commutation par blocs de 1 |
Notez qu'il est possible de sélectionner plusieurs tailles de commutations
en même temps (ils s'effectueront alors simultanément). Plus que de longs
discours, un bon exemple vous aidera à comprendre le processus. Exemple :
on fait une commutation de taille 1 et 4 :
move.b #%00000101,$DFF10C
|
On aura :
couleur0 <-> couleur1 (blocs 0 et 1)
couleur2 <-> couleur3 (blocs 2 et 3)
...
couleur254 <-> couleur255 (blocs 254 et 255)
|
Puis, avec le résultat obtenu :
couleur0 <-> couleur4
couleur1 <-> couleur5
couleur2 <-> couleur6
couleur3 <-> couleur7 (blocs 0 et 1)
...
couleur8 <-> couleur12
couleur9 <-> couleur13
couleur10 <-> couleur14
couleur11 <-> couleur15 (blocs 2 et 3)
...
couleur248 <-> couleur252
couleur249 <-> couleur253
couleur250 <-> couleur254
couleur251 <-> couleur255 (blocs 62 et 63)
|
Notez qu'une valeur de $00 dans $DFF10C correspondra à une palette normale et
$ff à une palette totalement inversée.
Le mode HAM8 (ou HAM+)
Le mode HAM8 n'est qu'une extension du précédent HAM (ou HAM6).
Pour déclencher l'un ou l'autre des HAM, il suffit de mettre le bit 11
de BPLCON0 à 1 et de fixer le nombre de plans de bits à 6 (HAM6) ou à 8 (HAM8).
Ensuite, les plans de bits sont divisés en deux groupes : les deux derniers
et les autres. Le décodage du premier bloc se fait de la manière suivante
(ordre : avant-dernier plan/dernier plan) :
- 00 -> les 4 ou 6 premiers plans de bits donnent le numéro du registre de couleur à utiliser
pour le point à afficher.
- 01 -> la couleur du point est déduite de celle du précédent :
le bleu et le vert restent les mêmes et les 4 ou 6 premiers plans de bits indiquent les
4 ou 6 bits de poids fort de la teinte rouge. Les bits non indiqués restent les
mêmes que ceux de la précédente couleur.
- 10 -> idem avec le bleu.
- 11 -> idem avec le vert.
NB : contrairement à ce qui est écrit partout, on n'est pas limité à 262 144
couleurs en HAM8 : en choisissant judicieusement sa palette de base, on peut en
afficher autant que l'on veut parmi 16,7 millions (autant que de pixels à l'écran).
La grande nouveauté est que l'on peut utiliser le HAM et le HAM8 dans tous les modes
de résolution (320, 640 et 1280 par 200 ou 400). Ce sont les infographistes qui vont être contents...
La saga des sprites
Au sujet des sprites, il y a beaucoup à dire. Tout d'abord, on peut maintenant
passer les sprites en haute résolution ou en super haute résolution.
Le choix du mode de résolution des sprites se fait à l'aide des bits 7 et 6 de BPLCON3 ($DFF106).
BPLCON3 : $DFF106
| bit 7 |
bit 6 |
Résolution |
| 0 |
0 |
Sprite en basse résolution |
| 1 |
0 |
Sprite en haute résolution |
| 0 |
1 |
Sprite en basse résolution |
| 1 |
1 |
Sprite en super haute résolution |
La largeur des sprites n'est plus limitée à 16 pixels :
on peut aussi définir des sprites de 32 ou 64 pixels de large.
Pour cela, on utilise les bits 3 et 2 de BPLCON4 ($DFF10C) :
BPLCON4 : $DFF10
| bit 3 |
bit 2 |
Largeur |
| 0 |
0 |
Sprite de 16 pixels de large |
| 1 |
0 |
Sprite de 32 pixels de large (spécial) |
| 0 |
1 |
Sprite de 32 pixels de large (normal) |
| 1 |
1 |
Sprite de 64 pixels de large |
NB :
- L'adresse mémoire d'un sprite de 16 pixels doit être paire (align 2 ou even sur MasterSeka).
- L'adresse mémoire d'un sprite de 32 pixels doit être multiple de 4 (align 4 sur MasterSeka).
- L'adresse mémoire d'un sprite de 64 pixels doit être multiple de 8 (align 8 sur MasterSeka).
Bien entendu, la modification de largeur du sprite influe considérablement sur sa structure de définition.
En 16 pixels, rien ne change :
mot C1,mot C2 ; mot de contrôle 1 et 2
mot A1,mot B1 ; plan de bits A et B ligne 1
...
mot Ai,mot Bi ; plan de bits A et B ligne i
$0000,$0000
|
En 32 pixels :
long C1,long C2 ; contrôle
long A1,long B1 ; plans de bits
...
long Ai,long Bi ; plans de bits
$0000,$0000,$0000,$0000
|
Seuls les 16 bits de poids forts de chaque registre de contrôle est apparemment pris en
compte (ce seront les mêmes que les mots de contrôle d'un sprite normal en 16 pixels).
Il existe deux types de sprites 32 bits : les normaux et les spéciaux. Pour les
normaux, les longs mots définissant les plans de bits sont entièrement pris en compte.
Pour les spéciaux, seul le premier mot de 16 bits de chaque long mot de plan de bits est
pris en compte : il sera répété deux fois à l'écran pour faire un sprite de 32 pixels de large.
En 64 pixels :
double C1,double C2 ; contrôle
double A1,double BI ; plans de bits
...
double Ai,double Bi ; plans de bits
$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
|
Comme pour les sprites en 32 pixels, seuls les 16 bits de poids fort de chaque registre
de contrôle sont apparemment pris en compte (ce seront les mêmes que les mots de contrôle
d'un sprite normal en 16 pixels).
Toujours en ce qui concerne les sprites, on peut maintenant
les placer à l'écran avec une précision d'un quart de pixel en largeur. J'en vois qui
doutent très fortement (comme moi à la première lecture de l'article). Ceci s'expliquerait de
la manière suivante : tout écran, quelle que soit sa résolution, serait converti avant
l'affichage par le coprocesseur graphique de l'Amiga en un écran d'une résolution de 1280
pixels en largeur (cette conversion restant transparente pour utilisateur). Cela permet
donc de placer les sprites ou de faire défiler l'écran avec une précision correspondant à
un écran de 1280 pixels de large.
Pour placer les sprites en horizontal, nous disposons donc de 11 bits dans HSTART au lieu de 9 :
- Bits 11 à 3 : dans le premier mot de contrôle, bits 7 à 0.
- Bit 2 : dans le second mot de contrôle, bit 0.
- Bits 1 et 0 : dans le second mot de contrôle, bit 4 et 3.
Malheureusement, nous n'avons pas trouvé d'amélioration en ce qui concerne le nombre
de couleurs sur un sprite : 4 en normal et 16 en mode attaché. Par contre, on peut maintenant
choisir la position de la palette du sprite grâce à BPLCON4 ($DFF10C) :
BPLCON4 : $DFF10C
- Bits 7 à 4 : définition de la palette des sprites pairs (sprites 0, 2, 4 et 6).
- 000 -> couleurs 0 à 15.
- 001 -> couleurs 16 à 31.
- ...
- 111 -> couleurs 250 à 255.
- Bits à 3 0 : idem avec les sprites impairs (1, 3, 5, 7).
NB : la première couleur de la palette n'est pas prise en compte :
elle représente toujours la couleur transparente. En mode attaché, c'est la
palette des sprites impairs qui est considérée.
Quelques astuces
Pour tous les créateurs de jeux et de démos, il est intéressant d'avoir un truc
pour détecter les puces AGA. Pour cela, il suffit de lire $DFF07C
(permet de connaître le numéro d'identification de Denise). Si on y trouve $F8,
c'est qu'il s'agit des puces AGA. Attention : cette méthode est bien pratique
mais ne survivra sûrement pas à une modification éventuelle des puces
AGA. Pour changer le mode d'affichage on utilisera le registre &DFF1DC.
Voici quelques valeurs intéressantes :
- 0 : passage en NTSC.
- 32 : passage en PAL.
- 128 : mode 72 Hz.
|
