 |
 |
 |
||||||||||||||
|
|
|||||||||||||||
 |
 |
|
Pas de compte ? S'inscrire... Statistiques |
Documentation
Rootretour à l'arborescence des catégories » Documentation techniqueEnsemble des informations pouvant être utiles au développement » Lynx docRestranscription de la documentation d'origine » Moteur de Sprite et de collisions » Fonctionnalités spéciales du moteur de sprite
«««« ( /^\ ) »»»»
INFOS SUR LA CATEGORIE
Créée le : 2009-09-20 17:00:00
Par : vince
Créée le : 2009-09-20 17:00:00
Par : vince
INFOS SUR LA PAGE
Titre : Fonctionnalités spéciales du moteur de sprite
Sous Titre :
Langue : FRA
Source : http://www.monlynx.de/lynx/lynx6.html#_62
Auteur : vince
Posté par : vince
Titre : Fonctionnalités spéciales du moteur de sprite
Sous Titre :
Langue : FRA
Source : http://www.monlynx.de/lynx/lynx6.html#_62
Auteur : vince
Posté par : vince
Fonctionnalités spéciales du moteur de sprite
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.
Fonctionnalités spéciales du moteur de sprite
1) Fonctions pour les numéros de stylos.
Les numéros de stylos vont de "0" à "F". Les stylos dont les numéros vont de "1" à "F" sont toujours sujets aux collisions et opaques. Il y a 13 stylos généralement utilisables pour le dessin ordinaire. Il y a 8 types de sprites, chacun possède des caractéristiques différentes qui s'appliquent à tout ou partie de ses stylos.
----1 Sprites normaux
Un sprite peut être paramétré en "normal". Ca veut dire que le stylo numéro "0" sera transparent et ne pourra pas servir pour les collisions. Tous les autres stylos seront opaques et pourront servir aux collisions. C'est le type de sprite qui est utilisés pour la plupart des images d'"actions", armes, ennemis, obstacles, etc...
----2 Les sprites à bordure
Un sprite peut être paramétré en "bordure". C'est comme un sprite en "normal" à ceci près que le stylo numéro "F" est transparent (et peut encore servir aux collisions). Ca permet à une bordure de recevoir une collision sans pénétration (comme un balle qui rebondit sur un mur).
----3 Les sprites ombrés
Un sprite peut être paramétré en "ombré". C'est comme un sprite en "normal" à ceci près que le stylo numéro "E" ne peut servir aux collisions (mais est opaque). Ca permet d'obtenir des ombres sans collision pour un sprite sujet aux collisions (comme l'ombre d'un arbre).
----4 Les sprites à bordure ombrés
Il s'agit d'un sprite "normal" avec en plus les caractéristiques des sprites à bordures et des sprites ombrés. C'est à dire que le stylo numéro "F" est transparent (et toujours sujet aux collisions) et que le stylo numéro "E" ne peut servir aux collisions (mais est toujours opaque).
----5 Les sprites ombrés d'arrière plan
Un sprite peut être défini en "arrière plan". Ce sprite écrasera le contenu des caches vidéos et de collisions. Les stylos "0" et "F" ne sont plus transparent. Ce sprite est utilisé pour initialiser le cache au début du dessin. Vu que les caches ne sont pas lu avant d'être écrits, le dessin de ce sprite prendra environ 1/4 de temps en moins. De plus, aucune détection de collision n'est effectuée et aucune écriture dans les zones de collision n'aura lieu. Il n'y a pas d'effacement automatique des caches de collision ou d'affichage. Si une initialisation est requise, elle peut être effectuée en utilisant un sprite d'"arrière plan".Notez que les octet partiellement utilisés (seulement un pixel) à chaque extrémité de la ligne de pixels feront un cycle de lecture-modification-écriture pour cet octet. Le pixel inutilisé restera inchangé.
NOTE IMPORTANTE : L'erreur "E" aura pour effet de rendre le stylo numéro "E" non sujet aux collisions et donc de ne pas effacer le cache de collisions. Si vous utilisez un sprite d'arrière plan pour effacer le cache de collision, soyez conscients que "E" n'effacera pas son pixel respectif.
----6 Sprite d'arrière plan sans collisions
C'est un sprite d'"arrière plan" mais pour lequel aucune activité ne survient sur le cache de collisions. Ce sprite nécessite 1/3 de temps en moins à être dessiné par rapport à un sprite d'arrière plan classique.
----7 Sprites sans collisions
Un sprite peut être paramétré en "sans collisions". Ca veut dire qu'il n'affectera pas le contenu du cache de collisions et que n'importe quelle autre activité de collision sont ignorées (le stylo "F" n'est pas sujet aux collisions). Vu que le cache de collision n'est pas touché, le processus de dessin de ce sprite va prendre environ un quart de temps en moins. Ce sprite peut être utilisé pour des images de "non action" comme les nuages, les cockpits, les tableaux de score, etc...
----8 Les sprites en OU Exclusifs
C'est un sprite "normal" à ceci près que les données du cache vidéo subissent un "ou exclusif" avec les données du sprite et sont alors écrites dans le cache vidéo. Le mode de fonctionnement des collisions est "normal". Vu qu'un cycle de lecture-modification-écriture est nécessaire pour chaque octet vidéo, ce sprite pourra être jusqu'à 1/4 de templs plus long à dessiner qu'un sprite "normal".
NOTE IMPORTANTE : L'erreur "E" aura pour effet de rendre le stylo numéro "E" non sujet aux collisions et donc de ne pas réagir avec le cache de collisions. Si vous utilisez un sprite en "ou exclusif", soyez conscients que "E" n'entrera pas en collision avec son pixel respectif.
----9 Détails matériels des types de sprite
Les types de sprites dépendent de fonctions matérielles spécifiques comme mentionné dans le tableau suivant :
Erreur d'ombre
Il manque au matériel un inverseur dans le générateur d'ombres. Cela a pour effet que les types de sprites qui n'invoquent pas l'ombre de l'invoquer et vice versa. La seule perte de fonctionalité que ça engendre est que les sprtes en "ou exclusif" ou les sprites d'"arrière plan" auront l'ombre d'activée. Le tableau ci dessus montre la NOUVELLE vérité
2) Conditions pour les octets de bordure.
Les octets contiennent plus d'un pixel, certains de ces pixels pourront être transparents, certains sprites pourront êtrede type arrière plan non aligné et certains stylos pourront être transparent. Plutôt que d'expliquer comment maîtriser toutes les variations de ces conditions, j'ai décidé de laisser le matériel s'en charger automatiquement. Par conséquent, quand vous utilisez le moteur de sprites pour dessiner l'écran, il n'y a pas de conditions spétiales pour les octets de bordure.
3) Etirement horizontal.
La taille horizontale d'un sprite peut être modifiée à chaque fois qu'une ligne de ce sprite est analysée. Ca inclue l'analyse des lignes quand le sprite est en dehors de l'écran. La modification consiste à ajouter une valeur d'étirement 16 bits (STRETCH sur 16 bits composé de STRETCHH et STRETCHL) à la valeur 16 bits (HSIZE) à la fin du traitement de cette ligne. Si la valeur d'étirement était de 0, aucune modification visible n'intervient. Cette modification n'intervient que si les bits de rechargement de SPRCTL1 l'autorisent. Etant donné que la valeur d'étirement sur 16 bits est constituée de 8 bits de dimension et 8 bits de fraction, l'incrément d'étirement peut être aussi petit que 1/256ème d'une unité de taille et aussi grand que 128 unités de taille. Une valeur de STRETCH supérieure à 128 unités aura pour effet un rebouclage dans l'unité de calculs arithémtiques et génèrera une réduction.
4) Etirement vertical.
La taille verticale d'un sprite peut être modifiée à chaque fois qu'une ligne de ce sprite est analysée. Ces spécificités sont les mêmes que pour l'étirement horizontal. La valeur utilisée est aussi la même que pour l'étirement horizontal. L'étirement vertical peut être indépendament activé ou désactivé. Bien que le facteur d'étirement soit additionné à chaque traitement de ligne, la nouvelle taille verticale prends seulement effet lors de la récupération de la ligne suivante.
5) Inclinaison.
La position horizontale d'un sprite pourra être modifiée à chaque fois qu'une ligne de ce sprite sera analysée. Ca inclue l'analyse des lignes quand le sprite est en dehors de l'écran. La modification s'effectue en deux étapes. La première est de récupérer une valeur entière d'inclinaison sur 8 bits en ajoutant la valeur 16bits de d'inclinaison (TILT sur 16 bits composé de TILTH et TILTL) avec l'accumulateur d'inclinaison (TILTACUM sur 16 bits composé de TILTACUMH et TILTACUML) à la fin du traitement d'une ligne et de décaler la réponse afin de mettre les 8 bits de poids fort en lieu et place des 8 bits de poids faible. La seconde étape consiste à ajouter cet entier à la position horizontale du sprite (HPOSSTRT sur 16 bits composé de HPOSSTRT et HPOSSTRTL). Cette modification n'a lieu que si elle est autorisée par les bits de rechargement dans SPRCTL1. Les incréments et contrainte de négativité sont les mêmes que pour l'étirement. Une valeur positive d'inclinaison déclenchera une inclinaison sur la droite. Si le sprite est dessiné vers la gauche (que ce soit du au quadrant ou au retournement) alors le logiciel aura a mettre une valeur négative d'inclinaison si une inclinaison à gauche est désirée.
6) Ignorance d'un sprite.
Le traitement d'un sprite peut être quasiment ignoré. La seule activité qui aura lieu sera la lecture des 5 premiers octets du SCB. Il est exigé que ces 5 octets soient validés, pour cela ils seront chargés dans le matériel. Notez que les deux derniers octets contiennent l'adresse du SCB suivant.
7) Décalage initial pour les dimensions horizontales et verticales.
Afin de compenser le "choc" visuel qui survient au point de référence d'un sprite à multi quadrant dimensionnés, on a implémenté une "astuce" consistant en une valeur pour le décalage initial pour les dimensions horizontales ET verticales. Elles sont programmées indépendament lors de l'initialisation du moteur de sprite. Pour l'horizontal, le décalage vers la gauche est forcé à 0 et celui vers la droite est programmée à 0x007F (127). Pour la verticale, le décalage vers le haut est forcé à 0 et celui vers le bas à 0x007F(127).
Quand vous utilisez des dimensions spécifiques pour obtenir des effets particuliers, vous devez prendre en compte ces décalages. Vous pouvez aussi les programmer à n'importe quelle valeur 16bits de votre choix. Elles sont communes à tous les sprites donc pensez à leur redonner leur valeur initiale si vous souhaitez revenir dans le cadre normal de l'utilisation des décalages.
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.
Fonctionnalités spéciales du moteur de sprite
1) Fonctions pour les numéros de stylos.
Les numéros de stylos vont de "0" à "F". Les stylos dont les numéros vont de "1" à "F" sont toujours sujets aux collisions et opaques. Il y a 13 stylos généralement utilisables pour le dessin ordinaire. Il y a 8 types de sprites, chacun possède des caractéristiques différentes qui s'appliquent à tout ou partie de ses stylos.
----1 Sprites normaux
Un sprite peut être paramétré en "normal". Ca veut dire que le stylo numéro "0" sera transparent et ne pourra pas servir pour les collisions. Tous les autres stylos seront opaques et pourront servir aux collisions. C'est le type de sprite qui est utilisés pour la plupart des images d'"actions", armes, ennemis, obstacles, etc...
----2 Les sprites à bordure
Un sprite peut être paramétré en "bordure". C'est comme un sprite en "normal" à ceci près que le stylo numéro "F" est transparent (et peut encore servir aux collisions). Ca permet à une bordure de recevoir une collision sans pénétration (comme un balle qui rebondit sur un mur).
----3 Les sprites ombrés
Un sprite peut être paramétré en "ombré". C'est comme un sprite en "normal" à ceci près que le stylo numéro "E" ne peut servir aux collisions (mais est opaque). Ca permet d'obtenir des ombres sans collision pour un sprite sujet aux collisions (comme l'ombre d'un arbre).
----4 Les sprites à bordure ombrés
Il s'agit d'un sprite "normal" avec en plus les caractéristiques des sprites à bordures et des sprites ombrés. C'est à dire que le stylo numéro "F" est transparent (et toujours sujet aux collisions) et que le stylo numéro "E" ne peut servir aux collisions (mais est toujours opaque).
----5 Les sprites ombrés d'arrière plan
Un sprite peut être défini en "arrière plan". Ce sprite écrasera le contenu des caches vidéos et de collisions. Les stylos "0" et "F" ne sont plus transparent. Ce sprite est utilisé pour initialiser le cache au début du dessin. Vu que les caches ne sont pas lu avant d'être écrits, le dessin de ce sprite prendra environ 1/4 de temps en moins. De plus, aucune détection de collision n'est effectuée et aucune écriture dans les zones de collision n'aura lieu. Il n'y a pas d'effacement automatique des caches de collision ou d'affichage. Si une initialisation est requise, elle peut être effectuée en utilisant un sprite d'"arrière plan".Notez que les octet partiellement utilisés (seulement un pixel) à chaque extrémité de la ligne de pixels feront un cycle de lecture-modification-écriture pour cet octet. Le pixel inutilisé restera inchangé.
NOTE IMPORTANTE : L'erreur "E" aura pour effet de rendre le stylo numéro "E" non sujet aux collisions et donc de ne pas effacer le cache de collisions. Si vous utilisez un sprite d'arrière plan pour effacer le cache de collision, soyez conscients que "E" n'effacera pas son pixel respectif.
----6 Sprite d'arrière plan sans collisions
C'est un sprite d'"arrière plan" mais pour lequel aucune activité ne survient sur le cache de collisions. Ce sprite nécessite 1/3 de temps en moins à être dessiné par rapport à un sprite d'arrière plan classique.
----7 Sprites sans collisions
Un sprite peut être paramétré en "sans collisions". Ca veut dire qu'il n'affectera pas le contenu du cache de collisions et que n'importe quelle autre activité de collision sont ignorées (le stylo "F" n'est pas sujet aux collisions). Vu que le cache de collision n'est pas touché, le processus de dessin de ce sprite va prendre environ un quart de temps en moins. Ce sprite peut être utilisé pour des images de "non action" comme les nuages, les cockpits, les tableaux de score, etc...
----8 Les sprites en OU Exclusifs
C'est un sprite "normal" à ceci près que les données du cache vidéo subissent un "ou exclusif" avec les données du sprite et sont alors écrites dans le cache vidéo. Le mode de fonctionnement des collisions est "normal". Vu qu'un cycle de lecture-modification-écriture est nécessaire pour chaque octet vidéo, ce sprite pourra être jusqu'à 1/4 de templs plus long à dessiner qu'un sprite "normal".
NOTE IMPORTANTE : L'erreur "E" aura pour effet de rendre le stylo numéro "E" non sujet aux collisions et donc de ne pas réagir avec le cache de collisions. Si vous utilisez un sprite en "ou exclusif", soyez conscients que "E" n'entrera pas en collision avec son pixel respectif.
----9 Détails matériels des types de sprite
Les types de sprites dépendent de fonctions matérielles spécifiques comme mentionné dans le tableau suivant :
| | Ombre de | | | Ombre et | Arrière plan | | Ombre en ou |
| Ombre | Bordure | Normal | Bordure | Arrière plan |Sans collisions|Sans collisions| Exclusif |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
| | | | | | | | |
F est opaque | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 1 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
E est sujet aux | | | | | | | | |
collisions | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
0 est opaque et | | | | | | | | |
sujet aux collisions | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
Permet la détection | | | | | | | | |
de collisions | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
Permet les accès au | | | | | | | | |
cache de collisions | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 1 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
Effectue un ou | | | | | | | | |
exclusif des données | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
-----------------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
Erreur d'ombre
Il manque au matériel un inverseur dans le générateur d'ombres. Cela a pour effet que les types de sprites qui n'invoquent pas l'ombre de l'invoquer et vice versa. La seule perte de fonctionalité que ça engendre est que les sprtes en "ou exclusif" ou les sprites d'"arrière plan" auront l'ombre d'activée. Le tableau ci dessus montre la NOUVELLE vérité
2) Conditions pour les octets de bordure.
Les octets contiennent plus d'un pixel, certains de ces pixels pourront être transparents, certains sprites pourront êtrede type arrière plan non aligné et certains stylos pourront être transparent. Plutôt que d'expliquer comment maîtriser toutes les variations de ces conditions, j'ai décidé de laisser le matériel s'en charger automatiquement. Par conséquent, quand vous utilisez le moteur de sprites pour dessiner l'écran, il n'y a pas de conditions spétiales pour les octets de bordure.
3) Etirement horizontal.
La taille horizontale d'un sprite peut être modifiée à chaque fois qu'une ligne de ce sprite est analysée. Ca inclue l'analyse des lignes quand le sprite est en dehors de l'écran. La modification consiste à ajouter une valeur d'étirement 16 bits (STRETCH sur 16 bits composé de STRETCHH et STRETCHL) à la valeur 16 bits (HSIZE) à la fin du traitement de cette ligne. Si la valeur d'étirement était de 0, aucune modification visible n'intervient. Cette modification n'intervient que si les bits de rechargement de SPRCTL1 l'autorisent. Etant donné que la valeur d'étirement sur 16 bits est constituée de 8 bits de dimension et 8 bits de fraction, l'incrément d'étirement peut être aussi petit que 1/256ème d'une unité de taille et aussi grand que 128 unités de taille. Une valeur de STRETCH supérieure à 128 unités aura pour effet un rebouclage dans l'unité de calculs arithémtiques et génèrera une réduction.
4) Etirement vertical.
La taille verticale d'un sprite peut être modifiée à chaque fois qu'une ligne de ce sprite est analysée. Ces spécificités sont les mêmes que pour l'étirement horizontal. La valeur utilisée est aussi la même que pour l'étirement horizontal. L'étirement vertical peut être indépendament activé ou désactivé. Bien que le facteur d'étirement soit additionné à chaque traitement de ligne, la nouvelle taille verticale prends seulement effet lors de la récupération de la ligne suivante.
5) Inclinaison.
La position horizontale d'un sprite pourra être modifiée à chaque fois qu'une ligne de ce sprite sera analysée. Ca inclue l'analyse des lignes quand le sprite est en dehors de l'écran. La modification s'effectue en deux étapes. La première est de récupérer une valeur entière d'inclinaison sur 8 bits en ajoutant la valeur 16bits de d'inclinaison (TILT sur 16 bits composé de TILTH et TILTL) avec l'accumulateur d'inclinaison (TILTACUM sur 16 bits composé de TILTACUMH et TILTACUML) à la fin du traitement d'une ligne et de décaler la réponse afin de mettre les 8 bits de poids fort en lieu et place des 8 bits de poids faible. La seconde étape consiste à ajouter cet entier à la position horizontale du sprite (HPOSSTRT sur 16 bits composé de HPOSSTRT et HPOSSTRTL). Cette modification n'a lieu que si elle est autorisée par les bits de rechargement dans SPRCTL1. Les incréments et contrainte de négativité sont les mêmes que pour l'étirement. Une valeur positive d'inclinaison déclenchera une inclinaison sur la droite. Si le sprite est dessiné vers la gauche (que ce soit du au quadrant ou au retournement) alors le logiciel aura a mettre une valeur négative d'inclinaison si une inclinaison à gauche est désirée.
6) Ignorance d'un sprite.
Le traitement d'un sprite peut être quasiment ignoré. La seule activité qui aura lieu sera la lecture des 5 premiers octets du SCB. Il est exigé que ces 5 octets soient validés, pour cela ils seront chargés dans le matériel. Notez que les deux derniers octets contiennent l'adresse du SCB suivant.
7) Décalage initial pour les dimensions horizontales et verticales.
Afin de compenser le "choc" visuel qui survient au point de référence d'un sprite à multi quadrant dimensionnés, on a implémenté une "astuce" consistant en une valeur pour le décalage initial pour les dimensions horizontales ET verticales. Elles sont programmées indépendament lors de l'initialisation du moteur de sprite. Pour l'horizontal, le décalage vers la gauche est forcé à 0 et celui vers la droite est programmée à 0x007F (127). Pour la verticale, le décalage vers le haut est forcé à 0 et celui vers le bas à 0x007F(127).
Quand vous utilisez des dimensions spécifiques pour obtenir des effets particuliers, vous devez prendre en compte ces décalages. Vous pouvez aussi les programmer à n'importe quelle valeur 16bits de votre choix. Elles sont communes à tous les sprites donc pensez à leur redonner leur valeur initiale si vous souhaitez revenir dans le cadre normal de l'utilisation des décalages.
(Source : http://www.monlynx.de/lynx/lynx6.html#_62)
«««« ( /^\ ) »»»»
-= DevLynx, un site par vince pour vous =-