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 - Initiation à la graphics.library
(Article écrit par Étienne Mouratila et extrait d'Amiga News Tech - mars 1990)
|
|
L'Amiga est une machine graphique. Cela signifie que tout ce que l'on peut voir à l'écran est
le résultat d'un dessin composé de figures géométriques simples ou complexes, dont les plus
primitives sont le point et la ligne.
En effet, contrairement, par exemple, au C64, il n'existe pas de "mémoire texte" dans laquelle
écrire le code ASCII, un caractère suffit pour l'afficher à l'écran. Tous les caractères de l'Amiga,
quelle que soit la police utilisée, sont dessinés "point par point" d'après une matrice stockée
quelque part en mémoire. Dans le même ordre d'idées, une fenêtre n'est finalement rien d'autre
qu'une combinaison de droites, arrangées d'une manière bien définie. La partie du système
d'exploitation qui s'occupe de gérer tout cela est encore une bibliothèque, fort judicieusement
nommée "graphics.library".
La graphics.library, résidente dans la ROM de l'Amiga, regroupe deux sortes de routines :
celles d'affichage (manipulation des couleurs, modes de dessin, etc.) et celles de dessin
proprement dit (point, droite, cercle, etc.).
Les bonnes résolutions
L'Amiga connaît plusieurs résolutions différentes, que le programmeur choisit en fonction
de ses besoins, et pour chacune desquelles il définit le nombre de couleurs à sa disposition -
avec toutefois une certaine limitation, due à l'arithmétique binaire. La résolution n'est
finalement rien d'autre que le nombre de points (pixels) visibles à l'écran.
Résolutions de l'Amiga :
| NTSC |
PAL |
Couleurs |
Nom |
| 320x200 |
320x256 |
32 |
Basse résolution (Lowres) |
| 640x200 |
640x256 |
16 |
Haute résolution (Hires) |
| 320x400 |
320x512 |
32 |
Basse résolution entrelacée (Lowres interlaced) |
| 640x400 |
640x512 |
16 |
Haute résolution entrelacée (Hires interlaced) |
| 640x200 |
640x256 |
16 |
Double champ de jeu ("dual playfield") |
| 320x200 |
320x256 |
64 |
Extra Half-Bright (EHB) |
| 320x400 |
320x512 |
64 |
Extra Half-Bright entrelacée (EHB) |
| 320x200 |
320x256 |
4096 |
Hold And Modify (HAM) |
| 320x400 |
320x512 |
4096 |
Hold And Modify entrelacée (HAM) |
Il existe trois principaux standards de télévision à travers le monde : le NTSC, le PAL et le SECAM.
Le mode NTSC est principalement utilisé aux États-Unis, PAL et SECAM étant, eux, plutôt européens.
L'Amiga est quant à lui capable de produire une affiche NTSC ou PAL. Les principales différences
entre les deux résidents dans la fréquence de rafraîchissement de l'image (50 Hz en PAL, 60 Hz en NTSC)
et dans le nombre de lignes affichées en vertical (PAL dispose de 56 lignes de plus en basse, et de 112
lignes supplémentaires en hautes résolutions).
Le nombre de couleurs varie, lui, en fonction du nombre de "bitplanes" employés. Par "bitplane"
(en français, champ ou plan de bits), on entend "zone de mémoire rectangulaire formant l'image" -
le terme "rectangulaire" n'est bien sûr qu'une vue de l'esprit, la mémoire étant linéaire.
Il faut imaginer que l'image que reproduit votre moniteur ou votre télévision, n'est en fait que
le résultat de la superposition d'un (?) ou plusieurs plans de bits. Plus le nombre de plans de bits
est élevé, plus on dispose de couleurs, mais plus on utilise de mémoire Chip. La relation est
la suivante :
nombre de couleurs = 2^nombre de plans de bits
|
(rappel : le signe "^" représente l'opérateur mathématique "puissance")
Par exemple, pour un affichage à 2 plans de bits comme celui du Workbench, on dispose de 2^2=4
couleurs simultanées. On peut utiliser au minimum 1 plan de bits, ce qui donne 2^1=2 couleurs, et
au maximum 5 plans de bits, ce qui donne 2^5=32 couleurs. Un sixième plan de bits est néanmoins nécessaire
pour les modes Extra Half-Bright et Hold And Modify.
Le nombre de plans de bits est défini, lors de l'ouverture d'un écran particulier (custom screen)
par Intuition, par le paramètre "Depth" de la structure "NewScreen" (voir
cet article
et celui-ci).
Les ViewPorts
Lorsque vous déplacez un écran vers le haut ou vers le bas à l'aide de la souris, le système affiche,
s'il y en avait un, le(s) écran(s) visible(s) derrière lui. Pour ce faire, il doit savoir en
permanence et pour chaque écran, où il commence et où il finit, l'adresse mémoire de chacun de ses
plans de bits, la palette de couleurs qu'il utilise, etc. Tous ces paramètres sont stockés dans une
structure C spéciale, nommée ViewPort.
Il n'est pas nécessaire d'en connaître la composition complète, seuls quelques éléments, que les
routines de dessin utilisent abondamment, sont à connaître. Nous les rencontrerons au fur et
à mesure de notre étude de la graphics.library.
Les RastPorts
De la même manière, un RastPort est une structure C toujours associée à un ViewPort. Elle
contient notamment les numéros de couleurs de dessin (APen et BPen), le mode de dessin (JAM1,
JAM2, COMPLEMENT, INVERSVID), le motif de remplissage pour les surfaces pleines, la position
du curseur graphique, la police en cours pour ce RastPort particulier, etc.
Chaque écran ouvert par Intuition contient, dans sa structure Screen, son ViewPort
et son RastPort. Une fenêtre étant toujours incluse dans un écran, sa structure Window
associée ne contient pas de pointeur sur un ViewPort, seulement sur son RastPort propre
(et donc différent de celui de l'écran).
Attention : le ViewPort et le RastPort dont partie intégrante de la structure Screen,
alors que l'on trouve dans la structure Window un pointeur sur son RastPort.
Ouverture de la graphics.library
Par la suite, et contrairement à tout ce qui a été fait dans l'initiation à l'assembleur
jusqu'ici, nous utiliserons les fichiers include ".i" fourni avec l'assembleur Devpac
2.12, histoire de simplifier et d'alléger les listings au maximum. Ceux d'entre vous qui
n'en disposeraient pas sont invités à laisser tomber illico leur vieux K-Seka préhistorique au
bénéfice du Devpac.
J'ai dit. Le répertoire d'inclusion, défini par la directive INCDIR, est en ce qui me
concerne, Include:. Modifiez-la suivant votre propre configuration.
Les macros CALLEXEC et GFXNAME sont définies respectivement dans include:exec/exec_lib.i
et include:graphics/graphics_lib.i.
Par la suite, nous n'utiliserons pour nos exemples que des écrans et des fenêtres déjà ouverts
par Intuition (fonctions OpenScreen() et OpenWindow() de la bibliothèque intuition.library),
bien qu'il soit possible de se créer soi-même un écran de toutes pièces, grâce aux routines de
la graphics.library.
Pour déterminer le ViewPort d'un écran et le RastPort d'une fenêtre, on utilise les instructions suivantes :
"screen" est un pointeur sur l'écran ouvert, "window" un pointeur sur la fenêtre ouverte.
Toutes les fonctions de la graphics.library, que nous allons maintenant étudier, requièrent
un pointeur soit sur le RastPort, soit sur le ViewPort. Le ViewPort est généralement pointé
par a0, le RastPort par a 1. Les divers paramètres nécessaires sont contenus dans les registres
de données Dn. La valeur de retour est toujours renvoyée dans D0.
Lignes et points
Pour tracer un point, on utilise :
A l'inverse, pour lire la couleur d'un pixel, on utilise :
Pour déplacer le curseur graphique sans tracer de point, on utilise la fonction Move() :
Le traçage d'une droite s'effectue toujours depuis la position actuelle du curseur graphique
jusqu'aux coordonnées spécifiées :
|
