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 - Outil de capture d'écran en IFF
(Article écrit par Max et extrait d'Amiga News Tech - juillet 1991)
|
|
L'utilitaire de ce mois va vous permettre de sauvegarder en tant qu'image IFF, n'importe quel écran Intuition
ouvert au moment de son invocation.
Ce type d'utilitaire existe déjà dans le domaine public, le plus célèbre étant - je pense - ScreenX, de
Steve Tibbett (également auteur de VirusX). Malheureusement, ScreenX agit selon un principe qui ne me plaît guère :
il ouvre une (petite) fenêtre sur le Workbench lorsqu'il est inactif et carrément un écran personnalisé (Custom Screen)
lorsqu'il est actif. Un petit panneau de contrôle est alors proposé, qui permet de choisir entre tous les écrans
ouverts, celui qui sera sauvegardé, voire imprimé. Bon.
De mon côté, je préfère et de loin le principe de YASS! (pour "Yet Another Screen Saver!". Les adeptes d'Unix
reconnaîtront la référence) : il ajoute un gestionnaire (handler) à la chaîne d'évènements gérée par l'input.device,
tout comme le CRBlanker de Frédéric Mazué, proposé dans ce même magazine quelques
mois plus tôt. Dès lors, à chaque fois qu'une certaine combinaison de touches est pressée, en l'occurrence Ctrl/Alt/Del
(encore une référence...), l'écran de front est sauvegardé par le programme principal dans un fichier IFF tout à fait
standard, visualisable et éditable par n'importe quel logiciel de dessin capable de comprendre ce format (c'est-à-dire
tous).
Préliminaires
La routine d'installation de l'input-handler est maintenant classique : on ouvre l'input.device et à l'aide de la
commande IND_ADDHANDLER, le gestionnaire est ajouté à la chaîne. Sa priorité est de 101, ce qui est
amplement suffisant pour le placer en premier dans la chaîne (rappel : l'input-handler d'Intuition
dispose d'une priorité de 51). Dorénavant, chaque fois qu'un évènement survient (souris, manette, clavier...),
le contrôle passe d'abord par notre gestionnaire, qui vérifie dans un premier temps que la tâche principale
n'était pas déjà en train de sauvegarder un écran, et dans un deuxième temps, que la bonne combinaison de
touches a été pressée. Si ces deux conditions sont remplies, il envoie un signal à la tâche principale,
qui commence alors son travail. Notez au passage que vous trouverez dans le listing, un équivalent assembleur
des fonctions CreatePort(), DeletePort(), CreateExtIO() et DeleteExtIO() de l'amiga.lib (je déteste relier !).
IFF
Le fichier IFF sauvegardé est parfaitement standard ; simplement, les gens de chez Electronic Arts piqueraient
sans doute une crise cardiaque s'ils voyaient de quelle manière on s'y prend...
L'écriture d'un fichier IFF est moins aisée que la lecture : il faut d'abord connaître la taille de chaque
bloc de données (chunk) avant de pouvoir l'inscrire dans le fichier. Or, pour connaître la taille d'un bloc
de données, il faut justement l'avoir déjà écrit... Ce qui oblige à quelques jongleries avec le DOS et la fonction Seek().
Pour éviter cela, on utilise un petit truc sachant d'une part que l'on n'écrit que les blocs de données réellement
indispensables (BMHD, CAMG, CMAP et BODY) et que d'autre part, le BODY n'est pas compressé, on peut connaître
la taille de la FORM avant même de l'avoir écrite : les blocs de données BMHD et CAMG sont de longueur constante
(respectivement 20 et 4 octets), seule les tailles du CMAP et du BODY sont à calculer. Ce calcul ne pose
toutefois aucun problème, tous les paramètres étant issus de la structure Screen et du RastPort de l'écran à
sauvegarder. A la taille ainsi calculée, on ajoute encore quelques octets nécessaires aux différents identificateurs
de blocs de données. Pour résumer, la taille de la FORM IFF sera :
- 4 octets pour "ILBM" ("FORM" et sa taille ne sont pas comptés).
- 28 octets pour le BMHD.
- 12 octets pour le CAMG.
- 8 octets pour "CMAP", sa taille, et le CMAP lui-même.
- 8 octets pour "BODY", sa taille, et le BODY lui-même.
Soit 60 octets, plus la taille du CMAP, plus la taille du BODY (essayez, vous verrez bien).
Pour ne pas allonger inutilement le programme, le nom du fichier à écrire est inclus directement dans
le source : il s'agit de "Ram:ScreenSaverimage". Ce qui implique qu'à chaque sauvegarde,
l'ancienne est écrasée. Il ne tient qu'à vous de modifier cela.
|
