Obligement - L'Amiga au maximum

Jeudi 23 novembre 2017 - 10:09  

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 - les sprites AGA
(Article écrit par Lionel Guillang et extrait d'Amiga News - février 1994)


Une des évolutions très intéressante apportée par le jeu de composants AGA concerne les sprites : si l'on reste malheureusement "scotché" à un maximum de huit (on peut continuer à rêver des 80 sprites de la Mega Drive ou des 100 de la 3DO), leurs caractéristiques ont, elles, été grandement améliorées (ouf !).

Quoi de neuf ?

Pour commencer, les sprites, tout comme les bitplanes et le Blitter, profitent de l'élargissement à 32 bits du bus et du mode double (64 bits) et on a donc maintenant la possibilité de les définir en 16, 32 ou 64 pixels de large.

De plus, on peut désormais leur donner l'une des trois résolutions horizontales standard (basse résolution, haute résolution, super haute résolution) et les afficher à 35 nanosecondes près (un pixel super haute résolution), et dans les bordures de l'écran.

Enfin, chacun des huit sprites peut maintenant avoir sa propre palette. A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !).

Concrètement

Avant toute chose, il est peut-être nécessaire de préciser que les variations de types sont globales : impossible par exemple d'utiliser simultanément des sprites de 16, 32 et 64 pixels de large, des sprites de différentes résolutions, etc.

Comment définir la largeur

La première chose à savoir est qu'elle est tributaire du mode de "fetching" (ECS, 2X ou 4X), de façon ascendante : par exemple, seul le mode 4X permet d'obtenir des sprites de 64 pixels : mais rien n'empêche de se limiter à des sprites de 32 voire de 16 pixels dans ce même mode (ça peut même, dans certains cas, libérer des cycles et permettre de récupérer quelques sprites). On activera la largeur désirée grâce aux bits 2 et 3 du registre FMODE :

Registre FMODE ($01FC):
    bits 3 2
         0 0 16 pixels (équivalent ECS)
         0 1 32 pixels normal
         1 0 32 pixels répétition
         1 1 64 pixels

Le mode répétition est un mode spécial permettant de conserver le bon ratio d'un sprite basse résolution de 16 pixels lorsqu'on passe en haute résolution : seuls les 16 bits de poids fort du corps du sprite sont pris en compte dans ce sas.

En mode 16 pixels, le corps du sprite est défini par deux mots pour chaque ligne (un mot par bitplane, précédés de deux mots de contrôle et suivis de deux mots nuls ou de deux nouveaux mots de contrôle si l'on est en présence d'une liste. Le schéma pour les modes 32 et 64 pixels est identique si ce n'est que tout est respectivement multiplié par 2 et 4. Voici ce que cela donnerait dans un programme :

Sprite 16 pixels :

dc.w   Ctrl1,Ctrl2
dc.w   xxxx,xxxx
...
dc.w   0,0

Sprite 32 pixels :

dc.w   Ctrl1,0,Ctrl2,0
dc.l   xxxxxxxx,xxxxxxxx
...
dc.l   0,0

Sprite 64 pixels :

dc.w   Ctrl1,0,0,0,Ctrl20,0,0
dc.l   xxxxxxxx,xxxxxxxx,xxxxxxxx,xxxxxxxx
...
dc.l   0,0,0,0

Ctrl1 :

Bits 15 14 13 12 11 10 09 08 07  06 05 04 03 02 01 00
     E7 E6 E5 E4 E3 E2 E1 E0 H10 H9 H8 H7 H6 H5 H4 H3

Ctrl2 :

Bits 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
     L7 L6 L5 L4 L3 L2 L1 L0 AT E9 L9 H1 H0 E8 L8 H2

"E" correspond à la première ligne raster du sprite et "L" à la dernière plus un. Et j'en viens maintenant tout naturellement au positionnement horizontal : comme vous pouvez le remarquer, l'ancien bit H0 s'est transformé en H2, l'ancien H1 en H3, etc. Ceci n'est pas un manque à la règle de la compatibilité ascendante puisque les nouveaux bits H1 et H0 ont été ajoutés pour le positionnement à 35 ns : en basse résolution (140 ns), le bit H2 correspond donc bien à l'ancien H0, ce n'est en fait qu'un décalage de la numérotation.

Bien entendu, le système de coordonnées et la résolution des sprites sont indépendants du bitmap, et il est par exemple tout à fait envisageable de produire des sprites super haute résolution sur un écran basse résolution. La résolution est définie grâce aux bits 6 et 7 du registre BPLCON3 ($0106) :

Bits 7 6
     0 0 compatible ECS
     0 1 basse résolution (140 ns)
     1 0 haute résolution (70 ns)
     1 1 super haute résolution (35 ns)

Voyons maintenant l'affichage dans les bordures : on l'obtient très facilement en mettant à 1 le bit 1 du registre BPLCON3 ($0106). Mais ce n'est pas tout : ce bit fait en effet partie d'une série qui peut être désactivée globalement (sorte d'interrupteur général) grâce au bit ECSENA (0) du registre BPLCON0 ($0100) et il faudra donc mettre aussi ce bit à 1. Je reviendrai là-dessus et vous donnerai un descriptif exhaustif de tous les registres de contrôle vidéo à la fin de cet article.

Je vous ai dit au début que chacun des huit sprites pouvait avoir sa propre palette, voici l'explication : tout se passe cette fois dans le registre BPLCON4 ($010C) : les bits 4 à 7 et 0 à 3 permettent de coder respectivement pour les sprites pairs et impairs la tranche de 16 couleurs qui doit leur être affectée.

Par exemple, $31 indique que la première couleur des sprites pairs sera la 48e et celle des sprites impairs la 16e. Étant donné qu'il y a quatre sprites de même parité et que chacun d'entre eux cet constitué d'au plus quatre couleurs (dont une transparente, la première) on obtient bien une palette propre à chacun. Les choses sont un peu différentes dans le cas de sprites attachés : on aurait aimé jouir d'un système équivalent (palettes différentes pour les quatre sprites possibles), mais ce n'est malheureusement pas le cas : on peut quand même choisir la tranche de 16 couleurs mais celle-ci s'applique à tous les sprites : on utilisera dans ce cas les bits 0-3 (sprite impairs).

Le tour d'horizon ne serait pas complet si on ne citait pas CLXCON2 ($010E). Ce registre est un complément à CLXCON ($0098) qui permet d'étendre les tests de collisions aux 7e et 8e bitplanes. Voici sa description :

Bit       Fonction
-------------------
15-08     inutilisés
07        ENBP8
08        ENP137
05-02     inutilisés
01        MVBP8
00        MVBP7

Je n'ai malheureusement pas la place pour détailler la façon d'utiliser ce registre : sachez simplement qu'il fonctionne de manière analogue à CLXCON sur lequel les documentations spécialisées ne manquent pas (ROM Kernel Manuals et autres Bibles), et qu'il est automatiquement remis à 0 lorsqu'on écrit dans CLXCON. Le registre CLXDAT demeure, quant à lui, inchangé.

Dernière remarque : contrairement à ce qui a pu être dit, il n'est pas obligatoire d'aligner les sprites en mémoire comme on doit le faire pour les bitplanes (adresse multiple de 8 pour un sprite de 64 pixels par exemple) : cependant, je ne saurais trop vous conseiller de le faire malgré tout, car il y a fort à parier que l'on doit perdre des cycles de bus en cas de mauvais alignement, même si l'affichage semble correct.

Le programme

Le source du mois illustre presque tout ce qui vient d'être expliqué. Il consiste à manipuler huit sprites de 64x64 ayant chacun sa propre palette, dans un écran virtuel de 1280x256, sans aucun bitplane derrière.

Notez que malgré l'absence de bitplanes, il est nécessaire d'initialiser DDFSTRT et DDFSTOP pour être sûr de disposer de tous les sprites. Ces mêmes sprites ne sont pas très jolis (rectangles remplis d'un motif algorithmique), mais rien ne vous empêche d'"incbin"er vos brosses préférées. Comme d'habitude, il est suffisamment commenté pour être, je pense, facilement compréhensible.

Assembleur
Assembleur
Assembleur
Assembleur
Assembleur
Assembleur

Erratum : Une inversion malencontreuse de lignes s'est produite dans ce listing. Dans la liste Copper, déplacez les deux lignes initialisant la couleur 0 (dc.w $0106,$0000,$0180, etc.), avant la définition de la palette (label "PalCop") et tout rentrera dans l'ordre.

Annexe

Voici un récapitulatif de tout ce qu'il faut savoir pour contrôler le système graphique AGA.

Assembleur

Les bits "x" sont actuellement inutilisés mais doivent être mis à 0 pour assurer une compatibilité ascendante.

Description des bits :
  • HIRES : active le mode HiRes (1640 pixels par ligne).
  • BPUx : nombre de bitplanes actifs (0 à 8).
  • HAM : active le mode HAM6 (BPUx=6) HAM8 (BPUx=8).
  • DPF : active le mode dual playfield.
  • COLOR : active le "burst" couleur sur la sortie vidéo.
  • GAUD : active le genlock audio.
  • UHRES : actise les pointeurs Ultra-HiRes.
  • SHRES : active le mode Super-HiRes (1280 pixels).
  • BYPASS : active la banque de couleurs transparentes.
  • LPEN : active le light-pen.
  • LACE : active le mode entrelacé (400/512 lignes).
  • ERSY : active la synchronisation externe.
  • ECSENA : inhibe (si à 0) les bits BRDRBLNK, BRDNTRAN, ZDCLKEN, BRDSPRT et EXTBLKEN.
  • PF2Hx : défilement matériel playfield 2 (0-63).
  • PF1Hx : défilement matériel playfield 1 (0-63).
  • ZDBPSELx : sélection bitplane transparent genlock.
  • ZDBPEN : active genlock sur bitplane défini dans ZDBPSELx.
  • ZDCTEN : active genlock vidéo (OR ZDBPEN).
  • KILLEHB : active mode 64 couleurs normal quand il y a six plans.
  • RDRAM : active lecture sur table des couleurs.
  • SOGEN : met la broche SOG à 1.
  • PF2PRI : playfield 2 prioritaire sur playfield 1.
  • PF2Px : priorité playfield 2 et sprites.
  • PF1Px : priorité playfield 1 et sprites.
  • BANKx : active une des huit tranches de couleurs.
  • PF20Fx : détermine les couleurs prioritaires du PF2.
  • LOCT : commute le poids fort/faible des composantes.
  • SPRESx : détermine la résolution des huit spriles.
  • BRDRBLNK : force la bordure noire et pas de couleur 0.
  • BRDNTRAN : inhibe genlock dans la bordure.
  • ZDCLKEN : active signal horloge 14 MHz.
  • BRDRSPRT : autorise les sprites hors bitplanes.
  • EXTBLKEN : autorise BLANK programmable en sortie.
  • BPLAMx : ou exclusif avec les numéros de registre couleur.
  • ESPRMx : sélectionne les palettes de sprite pairs.
  • OSPRMx : sélectionne les palettes de sprites impairs.


[Retour en haut] / [Retour aux articles]