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 - 16 millions de couleurs (HAM8) en AGA
(Article écrit par Lionel Guillang et extrait d'Amiga News - juin 1994)
|
|
Me revoici après une petite absence, due à une surcharge professionnelle !
Votre patience est récompensée puisque nous allons aujourd'hui lever le voile
sur le superbe (et controversé) HAM8, seul nouveau mode graphique spécial du
jeu de composants AGA. Si son principe est assez simple, sa mise en oeuvre, elle,
est déjà moins évidente...
HAM8
Sans plus attendre, voyons ce qu'est le HAM8 : 8 comme les 8 plans de bits nécessaires à son activation,
mais aussi pour le distinguer de son ancêtre le HAM, aussi appelé à posteriori HAM6 pour
éviter les confusions. Si l'idée du HAM8 est la même que celle du HAM6, il n'en est pas pour autant
le clone exact, nouvelle version : pour expliquer tout ça de façon simple, revenons au fonctionnement du
HAM6. Le HAM6 nécessite obligatoirement 6 plans de bits qui codent une information que l'on peut décomposer ainsi :
De ce tableau on peut déduire que le HAM6 permet d'accéder à l'ensemble de la palette 12 bits
(3x4), soit 4096 (2^12) couleurs simultanément. Faisons maintenant le parallèle avec le HAM8 :
Première différence qui saute aux yeux (n'empêche que...), les bits de contrôle sont désormais
dans les deux premiers plans. Seconde différence, on n'a plus accès directement à toute la palette
(24 bits en AGA) : les composantes des pixels dérivés ne sont codées que sur 6 bits et on a donc une
palette de 18 bits (3x6), soit 262 144 (2^18) couleurs simultanées pour chaque dérivation (bits "x"
dans le tableau). Mais on a 64 registres de base, donc 64 dérivations possibles, et on peut, pour
chacune des 64 couleurs de base, définir une combinaison différente des deux bits de poids faible de
chaque composante (bits "y" dans le tableau ci-dessus), soit 64 combinaisons possibles (2^6).
De tout ça, on peut déduire qu'il est possible d'obtenir 64 dérivations de 262 144 couleurs, toutes
différentes, et donc d'afficher 16,7 millions de couleurs simultanément. Ouf, c'est clair, non ?
Je tiens à rendre hommage à Philippe Rivaillon qui s'est exorbité les yeux pour pouvoir saisir les
variations de teintes dues aux différentes valeurs prises par les deux LSB des pixels dérivés (essayez,
vous verrez que ça n'est vraiment pas évident de faire la différence à l'oeil nu entre par exemple un
rouge $F0 et un rouge $F3 !).
Il semblerait qu'une fois de plus, les gens de Commodore soient un peu dépassés par leur propre machine
parce que toutes les docs techniques que j'ai eues entre les mains (et ça en fait !) se bornent à dire
que le nombre maximum de couleurs disponibles simultanément en AGA est de 262 144 ; ça rappelle le
bon vieux temps du C64 !
Dernière chose avant de passer à la pratique : à défaut de pixel pris dans la palette de base, les lignes
commencent avec les valeurs RGB de la couleur 0, tout comme pour l'ancien HAM. Ultime chose (!),
le mode HAM8 s'active très simplement en initialisant 8 plans de bits et en mettant à 1 le bit HAM (11)
du registre BPLCON0 ($0100).
Le programme
Comme je l'ai dit en introduction, la mise en oeuvre du HAM8 n'est pas vraiment simple,
pour ne pas dire même un peu tordue : donc si vous ne comprenez pas tout ce qui va suivre du
premier coup, n'ayez pas honte de relire jusqu'à ce que ce soit vraiment clair... Et ne m'en
veuillez pas trop, ça n'est pas plus facile d'expliquer !
Autant vous le dire tout de suite, le source de ce mois-ci ne va pas afficher 16,7 millions de couleurs
sur votre écran, pour des raisons de résolution, mais seulement (?) 262 404,
le tout en n'utilisant que quatre registres de base ; les pixels sont dessinés sur un écran
super haute résolution 1280x256, dans une fenêtre de 1026x256 : je sais, ça fait 262 656 pixels et
non 262 404, mais c'est parce que l'image contiendra 4 groupes de 64 pixels identiques, vous
allez comprendre pourquoi.
Le but de la manoeuvre est d'obtenir à partir des 256 rouges de la palette AGA un dégradé de 1025
couleurs, sur chacune des 256 lignes : pour obtenir ces 256 rouges de départ, on a besoin de dessiner
deux pixels : le premier définit les deux bits de poids faible et fait donc appel à la palette de base,
le second définit les six autres bits en modifiant la composante rouge : on a donc (2+1024)x256=262 656
pixels affichés, mais les pixels définissant les bits de poids faible du rouge sont répétés toutes les
4 lignes (2^2=4) ; les 6 bits de poids fort du rouge sont, eux, fixes durant les 4 lignes où les bits de
poids faible varient ; le second pixel de chacune des 256 lignes représente donc toujours un rouge pur
différent. Faites le calcul, tout ceci donne bien 262 656-252=262 404 couleurs différentes !
Le dégradé calculé avec les composantes vertes et bleues est réparti sur 4 lignes : cette fois on n'utilise
que les 6 bits de poids fort, ce qui donne une résolution de 12 bits donc 4096 couleurs : étant limités
par la largeur de l'écran, le dégradé est donc découpé sur 4 lignes de 1024 pixels. On passe en revue à chaque
ligne le spectre complet (sur 6 bits) des verts, tout en incrémentant et décrémentant de 4 la composante
bleue, que l'on décalera d'une unité à chacune des 4 lignes, obtenant ainsi le spectre complet des bleus
(toujours sur 6 bits !) sur les 4 lignes.
Voilà, si vous avez bien suivi ce qui précède, il doit vous apparaître clairement qu'on est très loin
d'avoir exploité toutes les combinaisons possibles : tout d'abord on a laissé de côté les 2 bits de poids
faible des composantes vertes et bleues (pour les utiliser, il suffit d'initialiser en conséquence les
60 registres de base inutilisés ici), ensuite les dégradés sur 4096 couleurs ne sont pas faits avec
une composante rouge constante puisque que celle-ci change à chaque ligne, et on aurait donc pu obtenir
4 fois plus de couleurs (un peu plus d'un million !), sans pour autant toucher aux bits de poids faible
des composantes vertes et bleues.
Comme vous pouvez le constater, le seul frein au fait de développer un visualisateur quasi parfait d'images
24 bits en HAM8, ne tient que dans la difficulté de programmer un convertisseur HAM8 de qualité, qui
exploite à fond ses possibilités : on peut d'ailleurs l'observer dans les différents programmes s'acquittant
de cette tâche qui donnent des résultats très variables : le nec plus ultra en la matière est, pour moi,
Deluxe Paint 4.5 qui fait bien mieux qu'ADPro, ce qui est un peu étonnant vu que ce dernier est en
théorie plus axé sur ce genre d'opérations. Reste que Deluxe Paint lui-même n'est pas encore parfait
et qu'il est certainement possible de faire mieux : pourquoi pas par vous ?
Je vous retrouve le mois prochain pour vous parler d'un sujet qui devrait en intéresser plus
d'un : la commutation des fréquences de balayage ! A plus...
|
