Obligement - L'Amiga au maximum

Samedi 18 novembre 2017 - 05:44  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · 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 in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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

 


Programmation : Assembleur - affichage 256 couleurs AGA
(Article écrit par Lionel Guillang et extrait d'Amiga News - janvier 1994)


Chose promise, chose due : voici de quoi en faire voir de toutes les couleurs à votre Amiga AGA, puisque nous allons nous pencher ce mois-ci sur les modes "True Color", le HAM nécessitant un article à lui tout seul. Allez, c'est parti...

True Color, késako ?

Derrière ce terme un peu savant que tous les graphistes connaissent bien, se cache en fait un concept très simple : à chaque couleur disponible dans la palette correspond un registre couleur. Le jeu de composants AGA autorisant une profondeur maximale de 8 plans, le nombre maximum de vraies couleurs est donc 2^8, soit 256.

Les registres couleurs

L'adressage des 256 registres de couleurs se fait sur 8 tranches de 32 registres chacune, à partir du registre COLOR ($0180). Ce n'est pas vraiment pratique, mais compatibilité oblige... On code le numéro de la tranche à laquelle on désire accéder dans les bits 13 à 15 du registre BPLCON3 ($0106). Contrairement au découpage quartets de poids fort/quartets de poids faible des composantes RGB (Cf. cet article), l'ordre dans lequel on accède aux différentes tranches n'a pas d'importance.

La bitmap

C'est maintenant que les choses se corsent un peu : il est en effet nécessaire de bien comprendre l'architecture du coprocesseur vidéo pour assimiler les nouveautés. Dans l'ancien jeu de composants, les données vidéo étaient véhiculées, via DMA, sous forme de mots (16 bits). Résultat : les pointeurs des bitplanes devaient donc être pairs pour être "fetchés" correctement. En AGA, le principe reste le même, mais devient plus flexible ; on peut désormais sélectionner quatre modes différents : le mode compatibilité qui émule les anciens jeux de composants (transferts 16 bits), le mode "burst 1", aussi appelé mode 2X, qui transfère les données sur 32 bits, le mode "double burst 1" qui transfère sur deux fois 16 bits (?), et enfin le mode "burst 2", ou 4X, qui transfère sur 64 bits. Vous l'avez compris, le plus performant est bien évidemment le mode 4X. La sélection du "fetching mode" se fait grâce aux bit 0 et 1 du registre FMODE ($01FC) :

Bit 1 0 Mode
--------------------------------
    0 0 normal 16 bits
    0 1 normal 32 bits
    1 0 double 16 bits (32 bits)
    1 1 double 32 bits (64 bits)

Seulement, cela amène aussi des contraintes d'alignement des bitmaps : en mode 2X, les pointeurs de bitplanes doivent être des multiples de 4 (32 bits), et en mode 4X des multiples de 8 (64 bits), pour être "fetchés" correctement. De la même façon, la largeur des bitplanes doit respecter ces alignements : on ne peut pas, par exemple, créer un vrai écran de 352 pixels de large (sans modulos) en mode 4X !

Toujours pour la même raison, les valeurs à donner aux registres DDFSTRT et DDFSTOP varient en fonction du "fetching mode", et leur précision diminue au fur et à mesure que la largeur de la bande augmente (16 pixels près en mode ECS, 32 en 2X et 64 en 4X). Attention, cela peut induire des erreurs : par exemple, en mode 4X, on peut initialiser DDFSTRT et DDFSTOP respectivement à $28 et $a8, ou bien à $38 et $a0. On obtiendra dans les deux cas, en apparence, un écran de 320 de large sans aucun décalage des lignes, mais dans le premier cas celles-ci seront "fetchées" inutilement plus tôt, nécessitant quelques cycles supplémentaires d'où disparition d'un ou plusieurs sprites, ralentissement du Blitter, etc.

En règle générale, il faudra mettre la valeur la plus grande possible dans DDFSTRT et la plus petite possible dans DDFSTOP : même si votre affichage semble correct du premier coup, faites d'autres essais !

En mode 4X, seules deux positions de fetching sont possibles de part et d'autre de l'écran : overscan (suraffichage) ou non : il semblerait donc qu'il ne soit pas possible de programmer un défilement Copper en suraffichage dans ce mode (devinez pourquoi !) : ce n'est pas bien ça !

Voici des valeurs standards pour des écrans non suraffichage centrés :

           LoRes     HiRes     S-HiRes
Mode ECS   $38-$d0   $3c-&d0   &3e-&d2
Mode 2X    $38-&c8   $38-&d0   $3c-&d0
Mode 4X    &38-&a0   $38-&c0   $38-&d0

N'oubliez pas que le pas diminue lorsque la résolution augmente (8 en LoRes, 4 en HiRes et 2 en Super HiRes !).

Autre nouveauté dûe aux nouveaux alignements : le registre BPLCON1 ($0102) a été étendu de façon à pouvoir gérer des décalages de 0 à 255, à 35 nanosecondes près, soit un pixel en Super HiRes (contre 0 à 15 et 140 ns sous ECS). Les quatre bits supplémentaires sont les bits 11-10/9-8 pour le premier playfield et 15-14/13-12 pour le second. Par exemple un décalage de 56 pixels LoRes sur les deux playfields sera codé en &CC88.

Voyons maintenant comment définir la profondeur et la résolution horizontale : l'initialisation de la profondeur se faisait auparavant grâce aux bits 12 à 14 du registre BPLCON0 ($0100). Cela n'a pas changé en AGA, à un détail près : 3 bits ne permettant de coder que 8 valeurs différentes (0 à 7), il faut avoir recours au bit 4 pour commuter en mode 8 bitplanes. Lorsqu'il est mis, les trois autres sont ignorés, inutile d'essayer d'activer 15 bitplanes !

En ce qui concerne les résolutions horizontales standards, pas grand-chose de neuf : leur initialisation se fait aussi grâce au registre RPLCON0 : par défaut on est en LoRes, le bit 15 active la HiRes, le bit 6 la Super HiRes. Pour l'anecdote, sachez qu'il existe une quatrième résolution horizontale possible, désignée par le doux nom de UHRES, c'est-à-dire ultra haute résolution ! Ne me demandez pas à quoi elle correspond, je ne suis pas encore parvenu à l'activer de façon satisfaisante : tout ce que je peux dire pour l'instant, c'est qu'il faut mettre à un le bit UHRES (7) dans BPLCON0 ($0100) mais apparemment il y a d'autres registres à initialiser (BEAMCON0 par exemple) (NDLR : la UHRES affiche un seul plan en 1024x1024 avec un seul sprite de disponible).

Autre nouveauté : les registres fenêtre (DIWSTRT et DIWSTOP) ont eux aussi été étendus : comme tous leurs bits étaient déjà affectés, un nouveau registre est apparu : DIWHIGH (&01E4). En voici la description :

Extension a DIWSTRT :

Bits 05   04   03   02   01   00
     H10  H1   H0   V10  V9   V8

Extension a DIWSTOP :

Bits 13   12   11   10   09   08
     H1O  H1   H0   V10  V9   V8

Les autres bits sont pour l'instant inutilisés et doivent donc être mis à 0. Les bits de position horizontales ont été décalés de façon à pouvoir définir la fenêtre à 35 nanosecondes près : l'ancien H0 est toujours H0 en LoRes (140 ns) mais devient H2 en Super HiRes ou H1 en HiRes (hum, c'est clair, non ?).

Et pour finir, les pointeurs de bitplanes : les quatre (2x2) supplémentaires nécessaires à une profondeur de 8 ont été ajoutés à la suite des anciens registres : ce qui donne $00F8 et &00FA pour le 7e plan, $00FC et &00FE pour le 8e.

Le programme

Le source que je vous propose ce mois-ci est un tantinet simplet, mais il présente l'avantage de bien mettre en évidence la façon d'activer un affichage 256 couleurs LoRes en mode 4X.

En résumé, il met en place un écran 320x256, dessine 256 rectangles de couleurs différentes, et cycle les 16,7 millions de couleurs disponibles, en AGA. Étant donné qu'il rafraîchit les 256 couleurs de la palette à chaque VBL, soit 50 fois par seconde, il faudra un certain temps (un peu plus de 20 minutes, faites le calcul) pour que le cycle complet s'accomplisse devant vos petits yeux émerveillés !

Ah oui, j'allais oublier : cette fois encore, l'écran actif au moment où vous lancerez le programme, doit être balayé à 50 Hz, sous peine d'obtenir un affichage distordu.

Le mois prochain, un peu moins de couleurs mais un peu plus d'animation, puisque nous aborderons les sprites AGA.

Assembleur
Assembleur
Assembleur
Assembleur
Assembleur
Assembleur


[Retour en haut] / [Retour aux articles]