Obligement - L'Amiga au maximum

Mardi 19 mars 2024 - 09:31  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

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

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des 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,
ALL


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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


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.


[Retour en haut] / [Retour aux articles] [Article suivant]