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
|
|
|
|
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 plans de bits 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 plan de bits, 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 plans de bits. 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 plans de bits (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 plan de bits derrière.
Notez que malgré l'absence de plans de bits, 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 de "incbin"er vos brosses préférées.
Comme d'habitude, il est suffisamment commenté pour être, je pense, facilement
compréhensible.
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.
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 (640 pixels par ligne).
- BPUx : nombre de plans de bits actifs (0 à 8).
- HAM : active le mode HAM6 (BPUx=6) HAM8 (BPUx=8).
- DPF : active le mode double champ de jeu ("Dual Playfield").
- COLOR : active le "burst" couleur sur la sortie vidéo.
- GAUD : active le genlock audio.
- UHRES : active 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 champ de jeu 2 (0-63).
- PF1Hx : défilement matériel champ de jeu 1 (0-63).
- ZDBPSELx : sélection plan de bits transparent genlock.
- ZDBPEN : active genlock sur plan de bits 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 : champ de jeu 2 prioritaire sur champ de jeu 1.
- PF2Px : priorité champ de jeu 2 et sprites.
- PF1Px : priorité champ de jeu 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 plans de bits.
- 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.
|
