Obligement - L'Amiga au maximum

Dimanche 23 septembre 2018 - 10:23  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Dossier : Le format IFF ILBM
(Article écrit par OK et Cancel et extrait d'Amiga News Tech - octobre 1989)


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. Il fut conçu par sept personnes : Bob Burns (Commodore-Amiga), RJ Mical (Commodore-Amiga), Jerry Morrison (Electronic Arts), Greg Riker (Electronic Arts), Steve Shaw (Electronic Arts), Dan Silva (Electronic Arts) et Barry Walsh (Commodore-Amiga). Il fut réalisé le 14 janvier 1985, soit durant le processus de développement de la machine. 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", alias "morceaux" en français).

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 (InterLeaved BitMap) : graphique.
  • PBM (Planar BitMap): 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 bitplanes du dessin.
  • CAMG (Commodore AMiGa) : mode de représentation.
  • SPRT (SPRiTe) : l'image est un sprite.
  • TINY (petit) : contient un petit aperçu d'une image.
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 offsets donnés :

Chunk BMHD
Offset 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 plan de bits
+9 1 octet Masquage :
0 = pas de masque
1 = masquage
2 = transparent
3 = lasso
+10 1 octet Compression :
0 = pas de compression
1 = compression "ByteRun1"
+11 1 octet Inutilisé
+12 1 mot Numéro de registre de couleur du 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)
Offset Taille Signification
+0 1 octet Valeur du rouge
+1 1 octet Valeur du vert
+2 1 octet Valeur du bleu

Chunk CAMG
Offset Taille Signification
+0 1 long Mode de représentation selon OpenScreen()

Chunk BODY
Offset Taille Signification
+0 Taille Données des bitplanes, compressées ou non
selon le BMHD. Les bitplanes sont disposées
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.


[Retour en haut] / [Retour aux articles]