Documentation

En plus des fonctionnalités habituelles qui accompagnent les sprites, deux fonctionnalités importantes sont présentes dans ce système. La première est que les sprites sont dimensionnés en temps réel par le matériel juste avant d'être dessinés sur l'écran. L'autre est que les données utilisées pour représenter l'image d'un sprite sont stockées en RAM dans un format compressé.

Liste des fonctionnalités:
¤ Les sprites ont une taille verticale illimitée
¤ La taille horizontale d'un sprite est limité par un maximum de 254 octets de données source. Ca équivaut approximativement à 508 pixels sans zoom.
¤ Les sprites ont 1,2,3 ou 4 bits par pixel pour le "numéro d'index de stylo". Les index de stylo sont convertis en numéro de stylos par le contenu d'une palette d'index de stylos de 16 quartets (8 octets) spécifique à chaque sprite.
¤ Le point de référence horizontale et verticale d'un sprite peut être défini sur n'importe quel pixel dans ce sprite au moment où le développeur compacte l'image d'origine. Le quadrant de départ doit également être précisé à ce moment. Le point de référence n'est pas modifiable dynamiquement pendant l'exécution mais le quadrant de départ l'est. Notez qu'il y aura une modification de la position si le quadrant de départ est modifié. L'image du sprite est ensuite dessinée dans chacun des 4 quadrants à partir de ce point de référence. Ca permet au sprites redimensionnés d'être référencés à leurs objets associés (les arbres avec le sol, les portes avec les murs, etc...)
¤ Le traitement d'un sprite peut être ignoré sur un sprite par les informations élémentaires du sprite.
¤ Les sprites ou les portions de sprites qui sont positionnés en dehors de l'écran seront coupés par le matériel pendant le procédé de dessin.
¤ Les sprites peuvent être retournés horizontalement, verticalement ou les deux. Le point de pivot est alors le point de référence du sprite.
¤ Les sprites sont dimensionnés pendant qu'ils sont dessinés. Ils peuvent être réduits ou agrandis. Les ratios de zoom à pour l'horizontale et pour la verticale sont indépendants.
¤ Les données source du sprite sont déballées pendant que le sprite est dessiné. Afin de permettre des modifications simples des données des sprites (texte, scores, etc...) l'algorithme d'emballage/déballage accepte les images dans un format litéral. La définition litérale n'affecte pas le zoom.
¤ Pendant qu'un sprite est dessiné, le cache de collision (topographiquement identique au cache d'affichage) est testé à la recherche d'un sprite dessiné au préalable. S'il y en a un qui existe, une collision intervient. Cette information de collision est enregistrée par le matériel pour pouvoir être lue par le logiciel par la suite. Plusieurs fonctions spécifiques sont exécutées par le matériel dans les données de collision afin de les rendre utilisables par le logiciel. Elles sont décrites ailleurs. Le logiciel peut choisir de ne pas avoir de buffer de collision et dégage ainsi 8Koctets de RAM supplémentaire pour le jeu. On peut définir individuellement les sprites comme n'étant pas sujet aux collisions et ainsi réduire le temps nécessaire au dessin.
¤ La taille horizontale d'un sprite peut être modifiée à chaque fois qu'une analyse de ligne est effectuée. Ca permet d'"étirer" un sprite verticalement et en liaison avec l'"inclinaison", ça peut être utile pour créer des polygones arbitraires.
¤ La position horizontale d'un sprite peut être modifiée à chaque fois qu'une analyse de ligne est effectuée. Ca permet d'"incliner" un sprite et en liaison avec l'"étirement", ça peut être utile pour créer des polygones arbitraires.
¤ La dimension verticale d'un sprite peut être modifiée à chaque fois qu'une analyse de ligne est effectuée. Ca permet d'"étirer" un sprite verticalement. Le facteur d'étirement vertical est le même que le facteur d'étirement horizontal. L'étirement vertical peut être définie sur un sprite par les informations élémentaires du sprite.