CODING ★ DE L'ARCADE A L'ACTION ★

De l'Arcade de l'Action n°30

Salut tout le monde. Vous savez que vous avez beaucoup de chance, car pour une fois, dans un canard, on vous balance plein de routines d'affichage de sprites et croyez-moi, il yen aura pour tous les goûts.

Laissons de côté tout le caca que l'on n'a pas appris a l'école buissonnière. Vous savez, si je veux faire un super mega tac-tac-poum-poum (moi-moi), je dois au moins savoir gérer un sprite de plein de façon, histoire de choisir celui qui convient le mieux (c'est comme pour les courses au Mammouth, on regarde pas seulement la qualité ou le prix mais les deux ensemble, d'ou le terme qualite-prix). A savoir, pour faire votre choix sur la méthode d'affichage adéquate, il faut se poser les questions suivantes :

Sur quel fond je travaille? (noir ou sur un décor), quel est le mode utilise (0 a 2), les sprites doivent passer devant ou derrière le décor? Ai-je assez de temps pour me permettre des calculs longs pour un affichage par point, ou je me réduis a travailler a l'octet ? Ai-je un rancart avec Delphine ce soir et je ne sais quoi encore?

Prenons les choses une par une, et, pour ne pas être trop brouillon, prenons ces choses par le début. Les choses, c'est les routines de sprite, et je vous en donne plusieurs quelque part dans ces pages, elles sont de plus en plus performantes et de plus en plus gourmandes en temps de calcul, donc de plus en plus lentes.

SOYONS BREF EN ECHANGE

La première n'est pas une routine de sprite (ya commence bien), elle remplace le BC26 de l'Amsdos ou votre propre BC26 car elle travaille sur le registre DE au lieu de HL.

Pourquoi ? Me direz-vous. Très bonne question, humm, humm. L'affichage d'un sprite est un transfert de la mémoire Ram vers la mémoire écran (&C000 a &FFFF). Si l'instruction LDIR est utilisée pour transférer les données d'une zone a l'autre, c'est le registre DE qui pointera a l'écran et HL sur le sprite mémorise par les routines du mois dernier. A partir de la, il est simple de comprendre qu'il vaut mieux réécrire la routine que d'utiliser deux EX DE,HL (avant et après avoir fait appel au BC26 classique), non? Ah, bon...
Ne vous laissez pas intriguer par le 8 place dans raccu qui s 'additionne a "D", car additionner &800 au registre DE ou 8 au registre 0 est strictement la même chose (c 'est Regis de MBM qui me l'a fait judicieusement remarquer). A propos de MBM, vous lui avez fait sauter sa boite aux lettres ? (cf. numéro 28 page 8).

Aussi différentes que soient ces routines de sprite. elles utilisent toutes le même noyau. A savoir. le registre DE pointe a l'écran, HL sur le sprite et B compte le nombre de lignes à afficher par sprite. Ensuite, on réutilise B pour faire soit un compteur de lignes, soit un transfert du type LDIR à travers BC. Dans tous les cas, on doit sauver BC par le premier PUSH de chaque routine qui sera désempile en fin de programme, pour bouder tant que toutes les lignes ne sont pas affichées. Idem pour DE qui se frotte le nez sur l'écran. On le sauve par un PUSH et en fin de transfert, on calcule son adresse inférieure après l'avoir récupère par un PUSH DE.
Il va de soi que, pour optimiser le tout, on pourrait se passer des opérations de sauvegarde du registre DE et faire les calculs du BC26 en fonction de la longueur du sprite. Seul inconvenant la routine ne marchera que pour les sprites de la même longueur, à vous de voir.

LES GOUTS
ET LES DOULEURS

La première routine est la simplicité même, c'est pour cette raison que je ne vais pas m'y attarder. On prend bêtement la valeur de chaque octet du sprite et on le force a l'écran. Bien sur, la matrice rectangulaire du lutin écrasera tout le contenu du décor Vous trouverez son utilité pour vérifier la bonne mémorisation de vos dessins ou, dans le cas d'animation, sur fond zéro (PAPER 0, au des octets écran remplis de 0).

XOR LE SHERIF DE L'ESPACE

A l'époque des Sorceri plus au pas plus et des Billy la banlieue beaux et pas beaux (1 et 2), le mode XOR était le chouchou des programmeurs. Dans toutes les autres routines, s'il y avait un décor, il fallait le sauver avant d'afficher le sprite et cela faisait royalement ch.... humm, humm, embêtait royalement le programmeur. Avec le mode XOR pas de problème de ce genre, on appelle la routine, elle affiche le sprite. on rappelle la routine, elle remet les choses comme au début. C'est propre et sans bavure, du mains presque car si le sprite passait devant un décor, on se retrouvait avec une cacophonie de couleurs en ut majeur pas conseille au puriste.

Mais bon, il a fait ses preuves et rien ne vous empêche de l'essayer. Son principe est simple: 1 XOR 1 = 0 et 1 XOR 0 = 1. Si on tient compte que 0 XOR 0 = 1 on en déduit très facilement que A XOR B sera égal a C et A XOR C sera égal a B. Vous voyez, on récupère notre B tout en l'ayant perdu de vue quelques instants (essayez en mode direct sous Basic, c'est magique).

UN PAR UN
OU UNE MARRAINE ?

La suite est plus intéressante. On place comme tout a l'heure les octets avec un plus qui est le test du contenu de l'octet sprite. Si cet octet est différent de zéro (AND A), on l'affiche, sinon on ne touche a rien. Le résultat, un écran assez propre avec en plus un zoli petit bonhomme place dedans.

Comme vous vous en doutez, le résultat n 'est pas encore parfait; en fonction des modes, on trouvera une traînée plus au mains importante autour du lutin. Prenons le mode 0 du CPC, par exemple. Chaque octet contient les valeurs pour des points cote a cote, imaginez le point a droite de l'octet a droite d'une ligne de sprites en rouge et son voisin de gauche de la couleur du fond; avec la méthode d'affichage par octet, on verra apparaître un point noir a gauche du lutin. C'est pire pour le mode 1 et catastrophique pour le mode 2. Mais bon, cela reste un très bon compromis dans le choix de votre routine.

ENCORE UNE PETITE

Et c'est la dernière pour aujourd'hui. On peut afficher un sprite derrière les décors; pour cela on teste l'0ctet à écran, si on trouve un zéro on place l'0ctet du sprite, sinon on continue la lecture. En deux mots, c'est l'inverse de la routine d'affichage par octet et elle garde les mêmes inconvenants.

Bon, assez pour les listings mais, comme vous vous en doutez, il existe encore un bon paquet de méthode pour l'affichage des sprites. Par exemple, on peut améliorer la méthode a l'octet au celle par transparence pour ne plus travailler sur un octet mais au pixel. Pour cela on utilise les instructions OR ET AND qui vident et testent les points a l'aide de masques.

Une autre bonne méthode consiste a remplir la future surface occupée par le sprite de l'encre 15 (c'est c;a un masque, le vrai qui sera place par des OR), ensuite le fond est tout propre pour afficher en force notre sprite par des AND. Et voila, plus de test de pixels. Sympa, non?

Que dire de plus si ce n'est que l'on peut choisir quelques couleurs pour les décors d'avant-plan et le reste des couleurs pour les décors d'arrière-plan et, en fonction des valeurs lues, afficher au pas les lutins ; ce qui donne un effet de profondeur au jeu car le personnage se baladera tantôt devant, tantôt derrière les objets. Il est évident que les dessins ne seront plus faits de la même fac;on et devront respecter une très grande rigueur.

ET LE DECOR DOCTEUR ?

La sauvegarde du décor pose toujours de gros problèmes aux débutants. Il existe également ici plusieurs méthodes. La plus simple, on sauve le rectangle sur lequel sera positionne le sprite, on affiche par une méthode que1conque le sprite, on attend un peu et on restitue écran pour continuer sur la sauvegarde et l'affichage.

Sachez deux choses, il faut se débrouiller pour avoir un laps de temps le plus court possible entre l'effacement du sprite et l'affichage de ce dernier, ce qui se comprend fort simplement en pensant que, durant ce temps, écran devient tout nu et le sprite disparaît momentanément du décor Le résultat d'une mauvaise programmation de ce genre est une animation qui clignote et c'est vraiment pas beau. Baaaaa, caca.

La deuxième chose a savoir est que pour obtenir un résultat parfait, il faut savoir se synchroniser avec le balayage de écran (FRAME en Basic, BD19 en Assembleur, IN A,(C) en Assembleur pro, etc.).

Je sais, vous n'y comprenez rien et vous vous dites : "il est bien gentil le petit Poum, il nous dit plein de trucs, genre Synchro-balai et des mots zarbi mais nous donne pas le mode d'emploi". Stop, ne vous affolez pas, ce sera le sujet de notre rubrique très bientôt et promis, il y aura plein d'exemples et si vous n'y comprenez encore rien de rien (non je ne regrette rien), allez faire un tour du cote de Jo Lascience, il est la pour vous servir de son mieux (avec tout son amour paternel).

Sur ce, amusez-vous-la bien et rendez-vous pris pour le mois de novembre.

Gros becots, Poum, ACPC n°30, oct90, p52-53

Dernière nouvelle: En possession des docs, Poum enlevé par les membres du Caca. Budget et d'autres sont sur ses traces mis, le mois prochain nous aurons notre revanche.

★ ANNÉE: 1990
★ AUTEUR: Alain Massoumipour

Page précédente : De l'Arcade de l'Action n°29

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » De l'Arcade de l'Action n°28
» Coding » De l'Arcade de l'Action n°29
» Coding » De l'Arcade de l'Action n°33
» Coding » De l'Arcade de l'Action n°31
» Coding » De l'Arcade de l'Action n°32
Je participe au site:

» 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 274 millisecondes et consultée 1679 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.