CODINGLISTINGS ★ LA TECHNIQUE DES MASQUES|CPC REVUE N°25) ★

La Technique des Masques (CPC Revue n°25)Coding Listings
Dans le numéro de mai de CPC, je vous avais déjà entretenu de la technique des masques. Technique qui permet de déplacer un sprite à l'écran sans en modifier les décors. Si, dans mon premier article, le phénomène était relativement bien expliqué, en revanche les routines utilisées étaient quelque peu archaïques. Un des défauts les plus évidents étant le crantage du déplacement._

Aujourd'hui, nous allons étudier le même effet, mais avec un déplacement plus couplé, un déplacement au pixel près. Si le résultat est de meilleure qualité, la technique à mettre en œuvre est plus complexe. Néanmoins, les opérations de base restent les mêmes :

INITIALISATION

  • Sauvegarde de la partie écran sous le sprite
  • Affichage du sprite

DEPLACEMENT

  • Test de déplacement
  • Remise à l'écran de la partie sauvegardée
  • Sauvegarde de la partie écran à la nouvelle position
  • Affichage du sprite

Il existe deux façons d'effectuer ces opérations et notre choix devra se faire en fonction de la taille du sprite.

Pour que le mouvement ne subisse pas d'à-coups, il faut que toutes les opérations décrites plus haut aient lieu entre deux balayages vidéo. Si notre routine est trop lente, notre sprite ne sera pas entièrement affiché lorsque le spot vidéo sera de retour. C'est à ce moment là que nous risquons d'observer ce que j'appelle l'effet dÿ TRICOT. Lorsque le sprite se déplace vers le haut de l'écran, il perd un pixel à chaque ligne tout comme un tricot perd ses mailles lorsque l'on tire sur le fil.

Suivant le mode avec lequel nous travaillons, nous aurons 8, 4 ou 2 représentations différentes pour un sprite. J'ai écrit mes deux routines pour le mode 1, il me faut donc quatre formes différentes pour mes sprites.

PREMIERE ROUTINE

L'avantage du premier programme est de calculer lui-même les quatre formes du sprite. Tous ces calculs demandent du temps et comme nous sommes limités par le retour du balayage vidéo, une telle routine ne pourra être employée que dans le cas d'un petit sprite.

Les différents essais que j'ai effectués m'ont prouvé qu'un sprite de 16 octets était la limite à ne pas dépasser. En mode 1, si nous avons 16 octets, cela représente exactement la taille d'un caractère ASCII (2 octets sur 8 lignes de pixels). Vous me direz qu'avec un si petit sprite, on ne peut pas faire grand-chose. Pourtant, c'est avec une telle routine que j'ai écrit 3D SNAKE (CPC n° 23). La boule qui se déplace à l'écran ne fait que 14 octets. Je vous laisse juge du résultat.
Les programmes 1 et 2 vous permettront de vous familiariser avec cette première technique.

L'initialisation se fait par CALL &A000,X,Y,Z.

X et Y étant les coordonnées et Z la couleur, les déplacements se font par CALL &A003,X,Y et les changements de taille du sprite par CALL &A135,NBLes 16 octets qui composent le sprite se trouvent à partir de l'adresse &A009.

Il est aussi possible d'effacer le sprite par CALL &A006.

Dans cette routine, la partie la plus complexe est constituée par le sous-programme effectuant la rotation des octets. C'est ce sous-programme qui prend le plus de temps car il est lu pour chacun des octets et par la-même en limite le nombre.

DEUXIEME ROUTINE

Ici, le sous-programme décrit précédemment a disparu. La rotation des octets ne s'effectue plus. Le programme affiche le sprite tel qu'il se trouve en mémoire. Puisque nous travaillons en mode 1, nous avons 4 pixels par octet, il faudra donc avoir en mémoire les 4 formes différentes du sprite. C'est le plus gros défaut de cette routine.

Dans le programme de démonstration que j'ai décrit, les quatre formes du sprite se trouvent sous forme de datas. Imaginez le problème si nous devions gérer plusieurs sprites. Nous serions vite noyés sous le nombre des datas. Dans ce cas de figure, je vous conseille de vous inspirer du programme écrit pour CHERRY PAINT dans le CPC n° 6, page 13. L'auteur, Pascal Higelin, a conçu un petit programme BASIC qui, à partir d'un seul sprite. calcule les autres formes. CHERRY PAINT étant écrit en mode 2, le programme calcule pour chaque sprite huit formes différentes. Il ne vous sera pas très difficile de le modifier pour obtenir le nombre de formes nécessaires au mode dans lequel vous travaillez.

Cette fois-ci, je pense que nous avons fait le tour de la question. Ces deux dernières routines ainsi que celles de mon premier article doivent vous permettre de répondre à tous les cas de figure. A vous d'en faire le meilleur usage.

Bon courage et à vos claviers...
Claude LE MOULLEC, CPC n°25

★ EDITEUR: CPC Revue
★ ANNÉE: 1987
★ CONFIG: 64K + AMSDOS
★ LANGAGE:
★ LiCENCE: LISTING
★ AUTEUR: CLAUDE LE MOULLEC

Page précédente : La Technique des Masques: RSX DEMOMASK
★ 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 » Graphic - C-Dragon (Amstrad Computer User)
» Coding Src's » Illusion
» Coding Src's » Dump anything off the screen (Computing With the Amstrad)
» Coding Src's » Pisać nie pisac (Bajtek)
» Coding Src's » XOR-Sprite (Schneider Aktiv)
» Coding Src's » Zellautomat (CPC Amstrad International)
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 779 millisecondes et consultée 817 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.