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
|
|
|
|
Le courrier des lecteurs d'Amiga News Tech - octobre 1989
(Rubrique animée par OK et Cancel et extraite d'Amiga News Tech - octobre 1989)
|
|
De plus en plus axé programmation (et ce en tous langages), l'Amiga News Tech possède dorénavant son propre
courrier technique. Nous ne pourrons de fait et malheureusement n'y traiter que les questions concernant
les problèmes de programmation que vous pourrez rencontrer sur Amiga. Soyez donc gentils d'éviter les questions
concernant l'imprimante XYZ qui n'est pas compatible avec le logiciel ABCD ou qui ne possède pas de pilote
adéquat, nous ne pourrons de toute façon pas faire grand-chose pour vous...
Format IFF ILBM
Bonjour, pourriez-vous me donner le format d'un fichier IFF ILBM, afin que je puisse intégrer des routines
de chargement/sauvegarde dans le logiciel graphique que je suis en train d'écrire (en langage C) ?
D'avance merci
[Jean-Luc Verlay].
Réponse
Mais certainement ! Comme vous le savez sans doute, le format IFF a été développé par Electronic Arts à
la demande de Commodore Amiga, afin de créer un standard pour la communication des données entre les
différents logiciels. Ce format inclut en fait non seulement les dessins bitmap créés à l'aide de programmes comme
Deluxe Paint, mais aussi les textes, musiques, sons échantillonnés, etc.
Les quatre premiers octets d'un fichier IFF contiennent toujours la valeur "FORM" (codée en ASCII, bien sûr).
Une forme en IFF sert justement à différencier les blocs de données contenus dans le fichier (et nommés "chunks").
Plusieurs formes peuvent être mises à la suite dans un même fichier.
On trouve ensuite un mot long (4 octets encore) contenant la longueur de cette forme, exprimée en octets.
Dans le cas d'un fichier IFF ne contenant qu'une seule forme, ce mot long sera égal à la taille du fichier
moins quatre. Un fichier IFF minimum aura donc une taille de huit octets : 4 pour "FORM" et 4 autres pour
la taille (0).
Suit alors un mot long (à nouveau 4 octets) indiquant le type du chunk. Il s'agit d'un mot de quatre lettres
ASCII, qui peut être :
- ILBM : graphique.
- WORD : texte.
- SMUS : musique.
- 8SVX : échantillon sonore 8 bits.
- ANIM : animation.
- etc.
Ce mot long est immédiatement suivi du nom du chunk à venir (4 octets) et de sa longueur (4 autres octets).
Il existe à l'heure actuelle beaucoup de noms de chunks possibles, mais voici toujours ceux que l'on peut
trouver dans un fichier ILBM (pas forcément dans l'ordre!) :
- BMHD (BitMap HeaDer) : caractéristiques du dessin.
- CMAP (Color Map) : table des couleurs.
- BODY (Corps) : données des plans de bits du dessin.
- CAMG (Commodore AMiGa) : mode de représentation.
On peut également trouver les chunks NAME et AUTH qui contiennent respectivement les noms de l'oeuvre et de son auteur.
Voici maintenant la description du contenu de chacun de ces chunks ; n'oubliez pas que le nom d'un
chunk est toujours suivi de sa longueur, exprimée sur un mot long, et non prise en compte dans les décalages donnés :
Chunk BMHD
Décalage |
Taille |
Signification |
+0 |
1 mot |
Largeur du dessin |
+2 |
1 mot |
Hauteur du dessin |
+4 |
1 mot |
Position X du dessin dans la page |
+6 |
1 mot |
Position Y du dessin dans la page |
+8 |
1 octet |
Nombre de plans de bits |
+9 |
1 octet |
Masquage
0 = pas de masquage
1 = masquage
2 = transparent
3 = lasso |
+10 |
1 octet |
Compression
0 = pas de compression
1 = compression "ByteRun"1" |
+11 |
1 octet |
Inutilisé |
+12 |
1 mot |
Numéro de registre de couleur de fond |
+14 |
1 octet |
Aspect X |
+15 |
1 octet |
Aspect Y |
+16 |
1 mot |
Largeur de la page source |
+18 |
1 mot |
Hauteur de la page source |
Chunk CMAP (pour chaque couleur)
Décalage |
Taille |
Signification |
+0 |
1 octet |
Valeur du rouge |
+1 |
1 octet |
Valeur du vert |
+2 |
1 octet |
Valeur du bleu |
Chunk CAMG
Décalage |
Taille |
Signification |
+0 |
1 long |
Mode de représentation selon OpenScreen() |
Chunk BODY
Décalage |
Taille |
Signification |
+0 |
1 long |
Données des plans de bits, commpressées ou non selon le BMHD. Les plans de bits sont disposés les uns à la suite des autres. |
Faites attention à ce qu'un chunk doit toujours être d'une longueur paire dans le fichier. Par exemple,
dans un chunk CMAP avec une seule couleur, la longueur utile du chunk, celle exprimée tout de suite après
son nom, serait 3, mais sa longueur véritable dans le fichier serait 4.
L'algorithme de compression utilisé porte le nom de "ByteRun1". Il est basé sur le principe du comptage des
octets identiques. Pour le décoder, il faut lire un octet, et comparer sa valeur à 128 :
- S'il est inférieur à 128, il faudra lire autant d'octets dans le BODY et les afficher tels quels à l'écran.
- S'il est supérieur à 128, l'octet suivant dans le BODY sera répété (257 octet) fois à l'écran.
- Enfin, une valeur égale à 128 indique... qu'il ne faut rien faire du tout !
On passe ensuite à l'octet suivant, et ainsi de suite jusqu'à la fin du fichier. Voilà qui, nous espérons, aura
répondu, peut-être même au-delà de vos espérances, à votre question. Remercions au passage Max, l'auteur de
l'initiation à l'assembleur 68000, pour ces précieux renseignements.
Musiques SoundTracker en GFA Basic
Je voudrais savoir s'il est possible d'intégrer des musiques créées avec SoundTracker dans ces programmes en GGA Basic ?
[Denis Jarril].
Réponse
Oui, cela est parfaitement possible, moyennant tout de même un petit peu de travail... et beaucoup de mémoire
(pas vous, l'ordinateur). Avant toute chose, il faut disposer du listing assembleur de la PlayRoutine, Listing
"diffusé" avec SoundTracker. Assurez-vous alors qu'elle est entièrement écrite en code relogeable (si mes souvenirs
sont bons, elle l'est). Assemblez-la avec le K-Seka et incluez votre module musical avec la commande RI.
Finalement, sauvegardez le tout avec ia commande WI. Vous obtenez sur la disquette un fichier contenant votre
musique et la routine assembleur pour la jouer, fichier qu'il ne reste plus qu'à inclure dans votre programme
en GFA Basic grâce à l'instruction INLINE. Par la suite, une simple instruction C: ou CALL suffira à lancer la musique.
ARexx ?
Qu'est-ce donc que ce fameux ARexx dont on entend parler un peu partout depuis quelque temps ?
Peut-on en savoir un peu plus sur le sujet ?
[Philippe de Menibus].
Réponse
Ouille, ouille, ouille... Ça risque d'être très difficile de décrire ARexx en quelques phrases...
C'est pourquoi je préfère vous laisser sur votre faim en vous promettant pour bientôt un article complet sur
le sujet. En attendant, sachez qu'un concurrent à nous (que je ne nommerai pas, mais bon, il n'y en pas 36)
a consacré une page entière de son dernier numéro à ce très intéressant langage.
Fichiers d'inclusion
Voilà, je débute en programmation sur Amiga, en assembleur pour être plus précis, et il y a quelque chose que je
ne comprends pas. Ne riez pas, c'est certainement tout bête : pourquoi certains programmeurs "incluent-ils"
des fichiers dans leurs programmes, et d'autres non ? Qu'apportent-ils concrètement, ces fichiers ? Et comment
puis-je, avec mon vieux K-Seka des familles, les utiliser ? [Olivier Vaneuken].
Réponse
C'est en effet tout bête ! Les fichiers dits "include" évitent au programmeur des tonnes de définitions d'ESUates
préliminaires ; ils contiennent entre autres choses toutes les constantes importantes pour la programmation du système de
l'Amiga, ainsi que les décalages de saut des fonctions des bibliothèques. Certains préfèrent les inclure dans
leur code source, d'autres préfèrent définir eux-mêmes les constantes dont ils auront besoin. C'est une question
de goût, uniquement. Quant à K-Seka, étant donné qu'il ne reconnaît pas la directive "include", seule la seconde
solution est valable.
|