[TUTO1] Gestion des sprites sur la Master-System

Voici un tuto sur la gestion des sprites sur master system. Un grand merci à Vingazole pour nous apporter son aide, c'est vraiment très gentil!

GESTION DES SPRITES SUR LA MASTER SYSTEM

ATTENTION : Afin de ne pas compliquer d’avantage le sujet je ne traite que de l’affichage correspondant aux valeurs de registres VDP que j’utilise dans le programme «tuto_sprite» (mode 192 lignes, adresses standard de la SAT,etc…)

La Master System permet d'afficher jusqu'à 64 sprites simultanément grâce à son processeur vidéo(VDP). Cependant le VDP n’autorise que 8 sprites par ligne au maximum.

Tous les sprites ont la même taille. Celle-ci dépend du bit n°1 du registre de VDP n°1 : s’il est à 0, tous les sprites font 8x8 pixels; s’il est à 1, tous les sprites font 8x16 pixels.

Les sprites utilisent les mêmes «tiles» (blocs de 8x8 pixels) que le background mais ne peuvent les afficher qu’avec la deuxième partie de la palette de 32 couleurs (les couleurs 0 à 15 des sprites correspondent aux couleurs 16 à 31 de la palette), alors que les tiles du background peuvent être affichées avec, au choix, l’une ou l’autre des deux demi-palettes de 16 couleurs.

Les données graphiques codant les tiles (character patterns)sont stockées dans la RAM vidéo(VRAM) à partir de l’adresse $0000, chaque tile utilisant 32 octets, à raison de 4 octets par ligne de 8 pixels (4 bits définissent la couleur de chaque pixel).
La tile n°0 est ainsi codée en VRAM de $0000 à $001F,
la tile n°1 est codée de $0020 à $003F,
la tile n°2 est codée de $0040 à $005F, etc…

La Sprite Attribute Table (SAT) définit chacun des sprites à l’écran. Elle utilise deux zones de la VRAM :

Les coordonnées verticales (y) des sprites sont stockées sur 1 octet depuis l’adresse $3F00 de la RAM vidéo, la coordonnée y du sprite n°63 se trouvant donc en $3F3F.
La valeur y = $D0 (208 en décimal) a une signification particulière puisqu’elle indique la fin de la table des sprites. En effet, si on écrit $D0 en $3F05, le VDP considèrera que la fin de la table est atteinte et n’affichera pas les sprites n°5 à n°63.

Les coordonnées horizontales(x) et les numéros de tile(n) à afficher en(x,y) sont quant à eux stockés en VRAM depuis $3F80, chaque donnée étant codée sur 1 octet : on ne peut donc utiliser que 256 tiles pour les sprites.

On a alors la coordonnée x du sprite n°0 en $3F80,
le numéro de tile du sprite n°0 en $3F81,
la coordonnée x du sprite n°1 en $3F82,
le numéro de tile du sprite n°1 en $3F83,etc…

Pour déplacer les sprites il suffit donc d’en modifier les coordonnées x et y, pour les animer on change le numéro de tile à afficher (on peut également garder la même tile et changer les 32 octets codant le «pattern» graphique) : il faut donc écrire dans la VRAM.

Ecriture dans la VRAM

L’écriture de données dans la RAM vidéo se fait en deux étapes :
définition de l’adresse où on veut écrire (port $BF = port de contrôle)
écriture des données (port $BE = port de données).

Définition de l’adresse

On doit envoyer successivement deux octets sur le port $BF :
le premier octet envoyé contient les 8 bits de poids faible de l’adresse
le second contient les 6 bits de poids fort de l’adresse (14 bits suffisent à définir une adresse en VRAM), le bit n°6 devant être forcé à 1 et le bit n°7 à 0 pour indiquer qu’on veut écrire en VRAM.

En assembleur z80, pour définir (par exemple) l’adresse $3F80:

ld a,$80 ; a = $80 (8 bits de poids faible de l’adresse)
out ($BF),a ; on écrit a sur le port de contrôle
ld a,$3F ; a = $3F (6 bits de poids fort de l’adresse)
or %01000000 ; on force le bit n°6 à 1, le n°7 étant déjà nul
out ($BF),a ; on écrit a sur le port de contrôle

remarque: le port $BF étant sensible à l’ordre d’écriture, on peut au préalable le «réaligner» en faisant :

in a,($BF) ; lecture du port $BF

Ecriture des données

On peut maintenant écrire notre nouvelle donnée en envoyant celle-ci sur le port $BE.

Pour écrire la valeur $CB à l’adresse que l’on vient de définir :

ld a,$CB ; a = $CB
out ($BE),a ; on écrit a sur le port de données

Le fait d’écrire dans la VRAM (c’est aussi valable pour la lecture en VRAM et pour l’écriture en CRAM) incrémente automatiquement l’adresse : la prochaine écriture se fera donc à l’adresse $3F81.

Ainsi, si on exécute maintenant :
ld a,$8A ; a = $8A
out ($BE),a ; la valeur $8A est envoyée sur le port $BE

La VRAM contient alors $CB à l’adresse $3F80
et $8A à l’adresse $3F81.

Couplée avec des instructions de bloc du z80 telles que OTIR (qui envoie ‘b’ octets consécutifs depuis l’adresse ‘hl’ sur le port ‘c’), cette fonction d’auto-incrémentation permet de transmettre très rapidement des blocs de données de la RAM ou de la ROM vers la VRAM (ou la CRAM).

Vous avez le fichier asm a compilé avec wla-z80 ici sous le spoiler:

Spoiler:

J'ai aussi le fichier .sms executable avec meka mais je peux pas le stocker sur le forum. Je pourrai vous le filer par mail si vous voulez (mais vu que vous avez le fichier .asm vous devriez pouvoir vous en passer)

Alex Kidd (Alex Kidd) Score : 2741 Date d'inscription : 15/11/2010 Age : 30

@Rotule:
Le sms executable

je crois que je commence déja mieux à comprendre

_________________
Have fun Playing

Alex Kidd (Alex Kidd) Score : 2741 Date d'inscription : 15/11/2010 Age : 30

Citation :: sprite_graph:
.db %00011100, 0,0,0 ; ligne 0 ; données graphiques du sprite
.db %01011101, 0,0,0 ; ligne 1 ; ----------------------------
.db %01001001, 0,0,0 ; ligne 2
.db %00111110, 0,0,0 ; ligne 3 ; on peut éditer directement le graph ici:
.db %00011100, 0,0,0 ; ligne 4 ; les '1' représentent les points allumés
.db %00011100, 0,0,0 ; ligne 5
.db %00010100, 0,0,0 ; ligne 6
.db %00110110, 0,0,0 ; ligne 7

hum... je ne sait pas à quoi correspondent les 3 paramètre "0,0,0" à chaque lignes(j'ai reussi à masquer certains points en y touchant, et on aurait dit que la conversion du %xxxxxxxx en décimal l'expliquait)

_________________
Have fun Playing

Humm...Le Doc chercherait-il à nous coller des devoirs de vacances? Rolling Eyes

ça sent l'interro surprise...

[quote="Piranahman"]

Citation :: hum... je ne sait pas à quoi correspondent les 3 paramètre "0,0,0" à chaque lignes(j'ai reussi à masquer certains points en y touchant, et on aurait dit que la conversion du %xxxxxxxx en décimal l'expliquait)

C'est pas évident à expliquer, je te conseille de consulter la doc officielle [url= http://www.smspower.org/Development/SMSOfficalDocs#BACKGROUNDSYSTEM][/url], au chapitre CHARACTER PATTERNS : les 4 bits codant la couleur du pixel sont répartis sur les 4 octets codant la ligne (le premier octet code donc le bit de poids faible des 8 pixels de la ligne concernée), chaque octet représentant un 'bitplane'.
Si tu veux que le pixel le plus à gauche aie la couleur 7 (%0111 en binaire), il faut coder %1xxxxxxx,%1xxxxxxx,%1xxxxxxx,%0xxxxxxx. Dans mon exemple je n'avais codé que la couleur 1 pour simplifier (%0001), c'est pourquoi les 3 autres valeurs étaient nulles : en donnant des valeurs non-nulles à ces octets tu as modifié le code de la couleur de tes pixels, et comme la palette ne contient que du noir (en dehors de la couleur n°17-qui je le rappelle correspond à la couleur n°1 des sprites) tu as "masqué" les points : tu peux le vérifier en donnant des valeurs affichables aux couleurs 18 à 31 (les 0 après le $3F dans mon programme ASM).

Alex Kidd (Alex Kidd) Score : 2741 Date d'inscription : 15/11/2010 Age : 30

Citation :: palette: .db 0, 0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ; couleurs 0 à 15 (background seulement)
.db 0,$30,$3F,$03,$02,0,0,0,0,0,0,0,0,0,0,0 ; couleurs 16 à 31 (sprites et background)

sprite_graph:
.db %00110011, %00001111,0,0 ; ligne 0 ; données graphiques du sprite
.db %00110011, %00001111,0,0 ; ligne 1 ; ----------------------------
.db %00110011, %00001111,0,0 ; ligne 2
.db %00110011, %00001111,0,0 ; ligne 3 ; on peut éditer directement le graph ici:
.db %00000000, %00000000,%00100000,0 ; ligne 4 ; les '1' représentent les points allumés
.db %00000000, %00000000,%00100000,0 ; ligne 5
.db %00000000, %00000000,%00100000,0 ; ligne 6
.db %00000000, %00000000,%00100000,0 ; ligne 7

résultat:

[TUTO1] Gestion des sprites sur la Master-System Output13

un petit drapeau français Very Happy

avec un poteau!

couleurs:
$30=Bleu (gauche du drapeau)
$3F=Blanc (milieu du drapeau)
$03=Rouge (droite du drapeau)
$02=Marron (poteau)

_________________
Have fun Playing

Alf (Alf) Score : 26 Date d'inscription : 17/07/2011 Age : 41

Ca me donne envie de m'y mettre tout ça !

en fait l ideal serait que chacun s y mette dans son coin et on fait le bilan dans qq semaines

merci à Vingazole d'avoir nous avoir éclairé la route ^^
je me pencherais la dessus dans 2/3 semaines, j'ai un peu autre chose sur le feu en ce moment Razz

Questions tout de même :
- la transparence des sprites ce fait quel niveau/comment ?
couleur 1 de la palette dédiée aux sprites (soit la 17ème)? ou c'est au choix & a définir ?
j'ai lu ton lien vers smspower et j'ai pas trouvé (mais j'ai lu rapidement...)

- pour grouper 4 sprites et en former 1 gros, t'as une fonction toute faite qui te recup les N sprites a partir d'une adresse X du SAT ?

Les sprites utilisent les couleurs 17 à 31 de la palette "globale", mais elles sont codées comme des valeurs de 1 à 15, la couleur 0 des sprites étant la couleur de transparence. La couleur 16 peut cependant être affichée en background en sélectionnant la "palette des sprites" (voir codage du background : c'est un des 16 bits codant la tilemap qui sélectionne la palette à utiliser).

C'est à toi de mettre autant de sprites que nécessaire pour en faire un gros (si tu veux un 16x16 pixels, il te faut par exemple 4 sprites 8x8 en ( x, y ),( x+8, y ),( x, y+8 ) et ( x+8, y+8 ) ou 2 sprites 8x16 (16 pixels de hauteur) en ( x,y ) et ( x+8, y ).

parfait, merci ^^

» [VDS] Master system 2 pack sonic en boite, jeux, master system 1
» ColeCoco Master - Adaptateur Colecovision pour Master System
» Samsung GamBoy System (la master system coréenne)
» Master System I
» Mod Master System