Documentation

Les données d'un sprite sont constituées d'un bloc de contrôle de sprite (SCB) et d'un bloc de données du sprite. Les SCB sont liés par des pointeurs dans l'ordre de dessin. Chaque SCB pointe aussi vers le bloc de données du sprite qui contient l'image en question. Plusieurs SCB peuvent pointer sur un même bloc de données de sprite. Chaque occurence d'un sprite à l'écran nécessite 1 SCB. Vu que tous les SCB et tous les blocs de données sont accédés via des pointeurs, ils peuvent par conséquent se trouver n'importe où en RAM. Ni les SCB ni les données de sprite peuvent être dans la ROM de Mikey

1) Bloc de contrôle de sprite
Chaque SCB contient certains éléments dans un certain ordre comme attendu par le matériel. De plus, d'autres éléments pourront être ajoutés par le logiciel en fonction des besoin. Le matériel ne sera pas au courrant ni impacté par ces éléments additionnels. Cette liste propose l'identification et l'ordre des éléments nécessaires et de quelques uns des éléments additionnels.

SCB en RAM (lié par ordre d'affichage)

Nombre d'octets ---|        |--- Premier élément dans la liste
                   |        |
                   V        V
                  (1)  8 bits de contrôle (SPRCTL0)
                  (1)  8 bits de contrôle (SPRCTL1)
                  (1)  4 bits de contrôle (SPRCOLL)
                  (2) 16 bits de pointeur vers le prochain SCB (0 pour le dernier)
                  (2) 16 bits de pointeur vers le bloc de données de sprite
                  (2) 16 bits de position de départ Horizontale
                  (2) 16 bits de position de départ Verticale
                  (2) 16 bits de dimension Horizontale
                  (2) 16 bits de dimension Verticale
                  (2) 16 bits d'étirement
                  (2) 16 bits d'inclinaison
                  (8) 64 bits de palette de stylos
La position de
cet élément est
arbitraire et     (1)  4 bits de dépot de collision
peut être fixée
dans n'importe
quel jeu

Il peut y avoir   (1)  8 bits de numéro d'identification
d'autres éléments (1)  8 bits d'ordre de profondeur
dans le SCB. Ceux (2) 16 bits de pointeur vers le SCB précédent (0 pour le premier)
ci et les autres
seront ignorés
par le matériel

Les 8 octets de palette de stylos sont traités par le matériel comme un bloc de données séparé du groupe d'octets le précédant dans le SCB. Ca veut dire que l'aptitude au rechargement de certains de ces octets n'affecte pas la réutilisabilité de la palette de stylos. De plus, ça veut dire que quand certains octets ne sont pas rechargés, la longueur du SCB sera plus petite du nombre d'octet inutilisés. Si jamais je n'ai pas été clair, tant pis.

2) Format de stockage des données
Toutes les données de sprites sont formatées. Le format consiste en une série de décalages et des données de l'image. Les données de l'image peuvent être totalement compactées, une combinaison de compactage et de données litérales ou des données exclusivement litérales. Le format est présenté ci dessous :

        Début des données du sprite-----------------------
                                                          \
                                                          V
       Décalage pour 2ème ligne de données de sprite---[ =2    ]--\
                                             Données---[       ]   |
       Décalage pour 3ème ligne de données de sprite---[ =N+1  ]<-/
                  Seconde ligne de données du sprite---[       ]  \
       (complétée de 0 jusqu'à la limite de l'octet)   ~~~~~~~~~   |
Décalage pour la ligne de données de sprite suivante---[ =N+1  ]<-/
    Changement pour la prochaine direction de dessin---[ =1    ]<-/ 
Décalage pour la ligne de données de sprite suivante---[ =N+1  ]<-/
                 Dernière ligne de données du sprite---[       ]  \
       (complétée de 0 jusqu'à la limite de l'octet)   ~~~~~~~~~   |
                            Décalage="0" pour la fin---[ =0    ]<-/

Paquet de données ordinaire

(1) bit de mode Litéral(1)/Compact(0)      }  Commun
===========================================
(4) bits pour le nombre d'itérations (+1)  \  Format compact
(1,2,3,4) bits par pixel de données        /
-------------------------------------------
(4) bits pour le nombre de pixels (+1)     \
(1,2,3,4) bits par pixel de données         \ Format litéral
                 .    .    .                /
(1,2,3,4) bits par pixel de données        /

Paquet intégralement litéral (le nombre de pixel dépends du décalage, cf spec)

(1,2,3,4) bits par pixel de données
(1,2,3,4) bits par pixel de données
                 .    .    .
Complété par des 0 pour finir l'octet

Direction du dessin

Le dessin des sprites est effectué en un à 4 quadrants. L'ordre de 
dessin des quadrants est Bas/Droite, Haut/Droite, Haut/Gauche, Bas/Gauche. Le
 quadrant de démarrage est spécifié dans les octets de contrôle. Un décalage 
 de "+1" indique au matériel de passer à la direction de dessin 
 suivante.

Bon, j'ai finalement trouvé le bug qui fait qu'on doit mettre un octet à 0 à la fin de chaque ligne de données. Il s'agit en fait de deux bugs. J'en ai résolu un mais l'autre implique des impacts importants. Malheureusement je manque de temps, donc :

Il y a un bug dans le matériel qui impose que le dernier bit représentatif d'un bloc de données à la fin d'une ligne ne soit pas dans le dernier bit d'un octet (bit 0). Ca veut dire que la création des blocs de données doit valider cette condition, et quand elle intervient il faut compléter le bloc par un octet remplit de 0. N'oubliez pas d'ajuster le décalage pour inclure ce complément. Comme ça ne surviendra que sur une ligne sur 8, ça ne justifie pas de me forcer à passer du temps à essayer de corriger ce bug, désolé.

Un entête de bloc de donnée de "00000" est utilisé comme un détecteur supplémentaire de fin de ligne de donnée de sprite. C'est généralement utilisé en guise de complément pour le dernier octet d'une ligne de donnée mais on peut le trouver n'importe où dans la ligne de donnée, pas uniquement sur le dernier octet. Notez que ça doit normalement décoder un bloc compact de 1 pixel. Merci d'utiliser le format litéral quand un bloc d'un pixel est nécessaire pour le graphisme. De plus, cet entête spécifique est utilisé quand une ligne sans pixel est désirée. Vous devez alors utiliser un décalage de 2 avec un octet de donnée remplit de "0" vu qu'un offset de 1 changerait la direction du dessin.

Oups, on dirait qu'il y a un bug, la vérité plus tard sur "00000"

Dans un sprite exclusivement litéral, il n'y a pas de comptage du nombre de pixels. Les données source sont converties en pixel au fur et à mesure que les octets des lignes de sprite sont lus. Les bits qui pourraient rester à la fin du dernier octet seront dessinés. Le bloc de données spécial "00000" n'est pas reconnu dans un sprite exclusivement litéral.