CODING ★ CRÉATION ET ANIMATION DE SPRITES ★

Graphic - CPC 28 - Creation et Animation de Sprites (CPC Revue)

AFFICHAGE D'UN SPRITE

Vous pouvez utiliser les tables données sous formes de datas ou bien, avec SURGENE, créer 3 tables de type travail (1 dans chaque mode). Tous les exemples donnés fonctionneront si chaque table contient au moins 3 sprites. La table créée par SURGENE devra être relogée en 40000 par SGMOVTAB. Elle ne doit pas dépasser 2,2 K. La dimension des sprites importe peu. Toutefois, pour mettre en évidence les avantages et inconvénients de chaque méthode, il est conseillé de créer un tout petit sprite (1/15 du maximum toléré par la grille), 1 moyen (environ 1/3), 1 grand (2/3). Valeurs données pour le mode 0. En mode 1 et 2, voyez plus petit, sinon vous dépasserez allègrement les 2 K.

Maintenant que nous disposons d'une table de sprites, notre problème est de l'implanter directement dans la mémoire écran. Pour y parvenir, il nous faut calculer :

  1. la position du sprite en adresse écran,
  2. convertir la ligne de données en un rectangle.

Pour ces opérations, le système Amstrad dispose de 2 routines ROM accessibles par vecteurs RAM.

1 - &BC1D (tous CPC)

Cette routine convertit une position pixel en adresse écran. Mais attention ! Souvenez-vous du chapitre sur les pas de déplacement. Avant d'appeler cette routine, les coordonnées y devront être divisées par 2. Les coordonnées X par 4,2 ou rien selon le mode écran 0, 1, 2. Ceci fait, X sera placé dans DE & Y dans HL. En sortie de &BC1D, HL contiendra l'adresse écran, B le nombre de pixels par octet, -1, C le cache pixel (ce dernier prendra toute son importance dans certains types d'affichage).

ATTENTION ! Ne pas tenir compte du pas de déplacement ou fournir des coordonnées hors écran, donnera un résultat incohérent.

0 3 LA A1 A2 A3 H L Pixels 1 2 3 H L Pixels
|--|--|--|--|--|---|-|-|------|-|-|-|-|--------| Etc.
| | | | | | | | | |
| | | | | | | | | +
| | | | | | | | ;Début données second sprite, etc.
| | | | | | | +
| | | | | | | Début pixels à afficher.
| | | | | | +
| | | | | | Dimensions sprite.
| | | | | +
| | | | | Début données premier sprite (3 octets réservés)
| | | +
| | | 40004 & 05 : Adresse du premier sprite, 40006 & 07 du second, etc.
| | +
| | 40002 & 3 : Contiennent l'adresse où finit la table (LASTAD)
| +
| 40001 : L'octet contient le nombre de sprites contenus dans la table
+ 40000 : L'octet contient le mode d'écran prévu pour l'affichage.

2 - &BC26 (tous CPC)

Cette routine calcule l'adresse écran située sous celle donnée en entrée. Si la valeur fournie dans HL avant l'appel est une adresse hors écran, le résultat renvoyé dans HL en sortie sera parfois surprenant.

LES ROUTINES DE LA MEMOIRE ECRAN N'EFFECTUENT AUCUN TEST DE VALIDITE.

LE PROGRAMME AFFISP

Structure de le table employée

La table se loge à l'adresse 40000. Elle est structurée comme ci-dessous :

Un dernier détail : à la fin de la table (LASTAD) sont stockés les numéros de couleur ayant servi à la création de la table : stylo 0 exclus. Le stylo de PAPER doit toujours être 0 et la couleur de l'encre affectée à ce stylo, initialisée par le programme exploitant.

Description du programme AFFISP

Assembleur : commentaires inclus au listing.

BASIC : ce programme se charge de passer les paramètres nécessaires au programme binaire. L'affichage se fait successivement dans les 3 modes. La case mémoire &B1C8 (464) ou &B7C3 (664-6128) contient le mode d'écran courant et permet de passer ce dernier à la routine binaire.
Essayez ce programme avec une valeur de PAPER différente de 0, vous constaterez que le dessin s'affiche au milieu d'un rectangle noir. Changez les coordonnées d'affichage et jugez des effets si elles sont situées en dehors de l'écran.

ANIMATION DE SPRITES

Maintenant que nous avons réussi à placer les sprites un peu partout sur l'écran, nous allons voir comment les déplacer. Ceci tout en conservant intact un éventuel décor en arrière.

Généralités

En programmation assembleur, le dilemme permanent est de choisir entre la rapidité d'exécution d'une routine et sa longueur en octets. Ces deux critères sont généralement incompatibles. Tous les exemples suivant donneront priorité à la vitesse d'exécution, au détriment de l'économie de mémoire.

Les vecteurs système

Ils sont aisés à employer, mais contraignent votre CPC à effectuer toute une petite cuisine interne : un RST 08, à la suite duquel le système échange les registres d'état avec leurs auxiliaires, sélectionne la ROM concernée après avoir déterminé l'adresse de la routine appelée, exécute la routine et doit encore revenir en RAM, au bon endroit de votre programme, ô, combien de cycles d'horloge et de microsecondes !... Et si cette routine est appelée plusieurs fois dans une boucle...
De plus, si la plupart de ces routines sont parfaitement adaptées aux besoins du système, elles ne le sont pas nécessairement aux nôtres. Ainsi, toutes les routines portant sur les calculs d'adresse
écran, utilisent de nombreux octets qui tiennent compte d'éventuels scrollings (dont nous n'avons actuellement pas l'usage).

Pour éviter ces pertes de temps, la routine &BC1D (conversion X-Y en adresse écran) ne sera utilisée qu'au premier affichage, le déplacement s'effectuera par des calculs effectués directement sur les adresses écran. De plus, nous allons créer deux routines pour remplacer les vecteurs &BC26 et &BC29.

La routine ADINF

Elle fonctionnera comme &BC26 Les lignes d'un même groupe sont séparées d'une valeur constante de &800. pour trouver l'adresse de la ligne inférieure, il suffit donc d'ajouter &800 à l'adresse de base. Si cette addition provoque une retenue, cela signifie que nous passons au groupe de 8 lignes suivant. L'écart entre la dernière ligne d'un groupe et la première ligne du suivant est de &37B0. Nous y ajoutons &800 pour compenser le résultat de la dernière addition soit &37B0 + &800 = &3FB0. En BASIC, faites ? HEX$(-&3FB0) vous obtiendrez &C050 qui sera la valeur correcte à ajouter pour passer à la ligne suivante. Notez qu'il est préférable d'additionner le négatif d'un nombre, plutôt qu'effectuer une soustraction. L'instruction ADD HL,DE gagne quelques cycles d'horloge par rapport à AND A (RAZ Carry), SBC HL,DE).

La routine ASDSUP

Donnera l'adresse de l'octet écran situé au-dessus de l'adresse donnée (&BC29 pour le système). Son principe de fonctionnement est exactement l'inverse de ADINF.

Les opérateurs logiques XOR -OR - AND

Si vous connaissez, sautez ce chapitre. Sinon, apprenez que l'on ne peut vraiment pas s'en passer et que ce n'est pas aussi compliqué qu'il y paraît. Il suffit de les considérer comme 3 filtres de type différent. Une ligne de 8 bits (1 octet) est filtrée par une seconde nommée masque ou cache et se trouve modifiée en fonction du type et contenu du masque.

AND : un bit de l'octet est mis à 0 si le bit correspondant du masque est aussi à 0, sinon il n'est pas modifié.
L'opérateur AND est généralement utilisé pour éliminer les bits indésirables d'un octet. Par exemple AND # DF, après un CALL # BB06, si la touche frappée est une minuscule, le résultat sera l'équivalent de cette lettre en majuscule. Les majuscules ne sont pas modifiées. Ce test n'est valable que sur les caractères alphabétiques de "A" à "Z". Il modifie les codes 95.

Donnée : 11111111 10001101 10011010

Masque : AND 00110010 AND 01110001 AND 00000000
; -------- -------- --------
Résultat : = 00110110 = 00000001 = 00000000

OR : tous les bits mis à 1, qu'ils soient dans le masque ou dans la donnée, se retrouvent à 1 dans le résultat. L'opérateur OR est utilisé pour mettre à 1 certains bits d'un octet. OR 32 passe les majuscules en minuscules. Mêmes remarques que précédemment.

Donnée : 00000111 11111111 00000000

Masque : OR 10100001 OR 00010101 OR 11111111
; -------- -------- --------
Résultat : = 10100111 = 11111111 = 11111111

XOR : deux bits identiques, dans le masque et la donnée donnent 0 dans le résultat, deux bits différents donnent 1. L'opérateur XOR peut être utilisé pour remettre un registre à 0. Noter que : donnée XOR masque, suivi de : résultat obtenu XOR le même masque restaure la donnée initiale. C'est cette propriété de XOR qui est utilisée dans le programme MSPXOR pour effacer le dessin en restituant le fond de l'écran.

Donnée : 01001101 10000001 01110101

Masque : XOR 11001100 XOR 11001100 XOR 01110101
; -------- -------- --------
Résultat : = 10000001 = 01001101 = 11111111

LE PROGRAMME MSPXOR

Sauvegarder le code objet sous le nom MSPXOR.BIN

Principe de fonctionnement :

0 : Initialisation mode et encres

1 : Calcul de la position du premier affichage (CONVER)

2 : Recherche du sprite dans la table et passage des paramètres (FINDSP)

3 : premier affichage par octet table XOR octet écran (AFFISP)

4 : Test joystick (JOYO)

5 : Effacement du sprite par un second affichage XOR

6 : Test de validité des nouvelles coordonnées. Si non valide -> 8

7 : Modification de VISAD & COINBD

8 : Affichage XOR à la nouvelle position

9 : Changement de sprite si FIRE pressé 10 : Retour en 4 ou au BASIC si ENTER pressé.

Quelques détails

1 - Le programme comporte 2 compteurs, (STEPX & STEPY) qui conditionnent les pas de déplacement du sprite. STEPX = nombre d'octets écran, STEPY = nombre de lignes écran. Ne jamais mettre un 0 dans l'un ou l'autre sinon DJNZ les met à 255 !

2 - FIRE est utilisé pour changer de sprite. L'écran s'efface et on passe au sprite suivant. Cette option vous permettra de constater les limites de ce type d'affichage. Si le déplacement des plus grands sprites pose des problèmes, ne vous inquiétez pas, c'est normal.

3 - La routine paramètres s'enrichit d'une option qui calcule la coordonnée opposée du sprite (COINBasDroite en adresse écran). C'est indispensable pour les tests de sortie écran.

4 - Tests de sortie d'écran. Si vous avez imprimé les résultats de SCRNMAP, cela vous sera bien utile.

– sortie en haut d'écran : l'octet fort de la première ligne écran est &CO. On teste l'ACTUELLE position de la ligne haute (VISAD), d'après cet octet. Si le résultat est différent de 0, la position supérieure est dans l'écran. Sinon, comme les 4 premiers groupes de ligne commencent tous par &C0, il faut encore tester l'octet faible pour voir s'il se situe ou non sur la première ligne du premier groupe (de &800 à &4F). Si ces deux tests sont positifs, VISAD & COINBD restent inchangés.

– Sortie en bas d'écran : comme ci-dessus, mais le test s'effectue sur la ligne basse du dessin (COINBD). L'octet fort de la ligne est & FF, ses 80 octets faibles vont de &80 à &CF.

– Sortie à gauche ou à droite de l'écran : c'est un peu plus complexe. L'organisation de la mémoire écran interdit une solution directe. La routine TSLINE nous donne l'équivalent de la colonne où se trouve le sprite sur la première ligne écran (de &C000 à &C04F). En sortie de cette routine, le test de l'octet faible (0 à gauche avec VISAD, &4F à droite avec COINBD), valide ou invalide le déplacement.

5 - L'initialisation du mode d'écran et des encres (INK, l,C1,C2) se fait d'après les données sauvegardées avec la table. Les données INK se terminent par un code # FF, d'où le BIT 7,B, JR NZ dans la routine FIXINK.

6 - Après lancement du programme MSPXOR.BAS, vous devrez fournir les pas de déplacement X & Y

7 - Ce programme fonctionne indifférement dans les 3 modes.

CPC n° 28

★ ANNÉE: 1988
★ AUTEUR: MICHEL MAIGROT

Page précédente : Graphic - CPC 27 - Creation et Animation de Sprites
★ AMSTRAD CPC ★ DOWNLOAD ★

Aucun fichier de disponible:
» Vous avez des fichiers que nous ne possédons pas concernent cette page ?
★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding Src's » 3D Donut (CPC Computing)
» Coding Src's » Graphic - Linear Regression (Popular Computing Weekly)
» Coding Src's » Test CRTC v2.3 (MADRAM, amslive n19)
» Coding Src's » The 3D World
» Coding Src's » Test CRTC v1.1 (Longshot)
» Coding » Graphic - CPC 27 - Creation et Animation de Sprites (CPC Revue)
Je participe au site:
» Vous avez des infos personnel, des fichiers que nous ne possédons pas concernent ce programme ?
» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 711 millisecondes et consultée 2862 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.