--== DEVLYNX ==--

 
 
|
 
 
 
 
Accueil
News
Doc
Mémoire
Recrutement
Faq
Liens
Pseudo :

Mot de passe :


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 » Description du moteur de collisions
«««« ( /^\ ) »»»»
INFOS SUR LA CATEGORIE

Créée le : 2009-09-20 17:00:00
Par : vince





INFOS SUR LA PAGE

Titre : Description du moteur de collisions
Sous Titre :
Langue : FRA
Source : http://www.monlynx.de/lynx/lynx6.html#_63
Auteur : vince
Posté par : vince

Description du moteur de collisions

Les sprites ont une valeur de collision sur 4 bits qui leur est associé. La fourchette de valeur est de 0 à 15. Ce nombre est dans le quartet de poids faible du troisième octet dans le SCB, "SPRCOLL". L'un des 4 bits du quartet de poids fort est utilisé par le matériel pour désactiver les collisions pour ce sprite. Les 3 autres sont ignorés par le matériel mais ils doivent être paramétrés à "0" pour la compatibilité future. Le logiciel doit assigner cette valeur de collision pour chaque utilisation de chaque sprite. Les règles pour ces assignations sont abordées dans une documentation logicielle.

Il y a un cache de collisions qui est topographiquement identique au cache vidéo. Le nombre de chaque "cellule" du buffer de collision est le numéro du sprite dont les pixels sont en collisions avec la "cellule" correspondante du cache d'affichage. Une valeur de "0" indique qu'il n'y a aucun objet sujet aux collisions dans ce pixel (bien qu'il puisse y avoir une image visible). N'importe quelle autre valeur est le nombre qui reste du précédent objet dessiné sur ce pixel. Ce cache est écrit par le processus d'affichage. Toutes les détections matérielles de collisions sont faites à partir du cache de collision, pas à partir du cache vidéo. Ca a des avantages évidents et ça sera expliqué en détail lors de séminaires et dans les lettres d'informations à venir.

Lorsque le travail pour chaque sprite sujet aux collisions est achevé, le matériel écrit un octet dans le "dépot de collision" des SCB de ces sprites. Le contenu de cet octet est le résultat du process de collision décrit plus bas. Une fois que tous les sprites sont dessinés, chacun aura une donnée pertinente dans leur dépot de collision. Ces valeurs pourront être lus plus tard par le CPU afin de détecter es collisions.

De plus, le logiciel peut soit effectuer lui même sa propre détection de collision, soit utiliser le contenu du cache de collision pour un quelqu'algorithme tordu de détection de collision. Dans les deux cas je me sentirais personnellement et mortellement humilié. Sur 42 générations.

1) Processus de collision
Pendant le dessin des sprites dans le cache vidéo, le processus de collision a lieu lui aussi. Notez que le processus de collision N'intervient PAS quand le CPU accède directement le cache vidéo. Le processus de collision est aussi désactivé par la sélection d'un type de sprite approprié ou par le positionnement de n'importe lequel des bits de désactivation. Si le sprite est sujet aux collisions, le matériel écrira dans le dépot de collision chaque fois que le sprite sera dessiné, imposant au logiciel d'effacer cette valeur après avoir détecté une collision. Si le sprite n'est pas sujet aux collisions, le matériel n'écrira pas dans le dépot de collision et le logiciel pourra vouloir initialiser l'octet du dépot avec une valeur "sûre". "Toujours allumé" déclenchera aussi une écriture sur l'octet du dépot. Si plus d'une collision avec un objet a eu lieu, le nombre retenu sera le plus fort de l'ensemble des collisions détectées.

Si le dépot de collision d'un sprite est à zéro, alors ce sprite n'est entré en collision avec aucun autre objet sujet aux collisions pendant qu'il était dessiné dans le cache vidéo. Ca ne veut pas dire que ce sprite n'entrera en collision avec aucun autre objet qui sera dessiné plus tard ou qu'il n'est pas en contact visuel avec un autre objet, ça veut juste dire que les pixels sujets à collision sur ce sprite n'ont été superposé avec aucun pixel sujet aux collisions qui était DEJA dans le cache de collisions. Si, plus tard, un sprite est dessiné et qu'il entre en collision avec ce dernier, alors c'est ce nouveau sprite qui enregistrera la collision.

Si la valeur dans le dépot de collision d'un sprite est différente de 0 alors ce sprite est entré en collision avec un objet qui existait déjà dans le cache de collisions. La valeur dans le dépot de collision est le numéro de collision de l'objet qui a été frappé. On peut espérer que le logiciel attribuera les numéros de collisions d'une manière sensée. Mon souhait pour une assignation sensée est que les numéros soient assignés dans l'ordre de profondeur visuelle de sorte que les détections de collisions par le matériel soient représentatives des collisions visuelles.

2) Dispositifs anti collisions(c'est pas ce qu'on appelle un parechoc ?)
Afin de contenter la plèbe, les collisions matérielles sont désactivables de plusieurs façons.
¤ La méthode originale consistant à définir un sprite de type "sans collisions"
¤ Activer le bit "pas de collisions" dans le numéro "SPRCOLL" de collision du SCB
¤ Activer le bit "pas de collisions" dans l'octet de contrôle système "SPRSYS"

Ces bits surpassent tous les autres paramétrage de collision et désactiveront l'activité du moteur de collision pour le sprite courrant (avec "SPRCOLL") ou pour tous les sprites (avec "SPRSYS").

(Source : http://www.monlynx.de/lynx/lynx6.html#_63)
«««« ( /^\ ) »»»»

générée en 4 ms
-= DevLynx, un site par vince pour vous =-