CODING ★ DE L'ARCADE A L'ACTION ★

De l'Arcade de l'Action n°33
Mes amis, je suis dans l'obligation de vous annoncer une très mauvaise nouvelle. En effet, la rubrique que voici touche à sa fin. Je crois avoir fait le tour des points les plus importants utilisables lors de la création de vos jeux d'arcade. La balle est désormais dans votre camp et j'attends avec grande impatience vos jeux pour me réconforter lors des rudes nuits d'hiver à venir.

Ne vous inquiétez surtout pas. Premièrement, je ne vous laisserai pas sans vous faire une grosse surprise. Deuxièmement, nous devons absolument voir la façon dont les tableaux d'un jeu peuvent être stockés en mémoire. Troisièmement, le téléphone et le courrier peuvent comme d'habitude vous servir pour nous contacter et nous faire part de vos difficultés. Quatrièmement, Robby n'est pas le plus beau.

ERRATUM

Avant de me lancer dans de longs propos, acceptez toutes mes excuses en ce qui concerne la plus grosse bêtise de ma vie, passée dans ces mêmes pages le mois dernier. Dans le source (comme dans l'article), ne me croyez surtout pas quand je vous annonce que INC L peut remplacer INC HL. On a voulu me le faire croire et bonne poire comme je suis, je l'eusse tout cru (quelle nouille !).

DEUXIEMEMENT, LES TABLEAUX

Il existe deux façons correctes pour créer les tableaux d'un jeu d'arcade. La premiere et la plus belle, tout en étant la plus barbare et la plus gourmande en place sur disque, est l'affichage des desdits tableaux en tant que pages écran. Vous comprenez aisément que chaque level prendra 17 Ko sur votre disquette et qu'il faudra un autres bon travail de la part de votre graphiste pour un rendu parfait.

Une tout petite variante consiste à gruger en n'affichant qu'une grosse fenêtre (ou un très grand sprite) en plein milieu de l'écran. Remplir le reste d'une couleur quelconque pour donner l'illusion d'un sol ou du ciel (le meilleur exemple de cette technique est Bob Winner de Loriciel). Rien n'empêche de compacter ces écrans à l'aide d'un bon compacteur et vous verrez rapidement que le tout reste jouable.

La deuxième méthode reste tout de même la plus employée. Chaque écran est formé d'une combinaison finement choisie dans une table de sprite. On dessine un bon paquet de petits lutins (bout de sol, herbe, colonne, ciel, rochers et je ne sais quoi encore) et, en les assemblant, on crée nos décors. Pour rester dans la limite du raisonnable, choisissez des sprites de grosse taille, ainsi un écran formé avec des rectangles de 4 octets sur 16 lignes ne demandera qu'une toute petite place de 200 octets en mémoire. Pour stocker le tout, dessinez dans un premier temps vos écrans sur papier, notez le numéro de chaque sprite et placez-les à l'aide d'un petit prog Basic en mémoire. Dans le cas précédent, un tableau est formé de 20 sprites par ligne, sur 10 lignes.

Alignez 20 tableaux (4000 octets en mémoire), tout en sachant que chaque sprite est représenté par sa position (de 1 à ?) dans une table de sprite. Le reste est simple. Vous connaissez le numéro du tableau à afficher?

LD A,POSITION
DEC A

HL = 200*A (voir une multiplication)

Et zou. HL pointe sur le début des jonnées du tableau courant. De même, il suffit de lire un par un les octets pointés par HL et de trouver la place des sprites avant de les afficher. Ne vous affolez pas, cela reste très rapide à l'exécution et le joueur n'y verra que du feu.

POUR PRENDRE ENCORE MOINS DE PLACE

Il va de soi qu'un jeu formé de 300 tableaux saturerait rapidement la place mémoire utilisable. Alors, de deux choses l'une vous découpez le jeu en plusieurs parties et faites des accès disques de temps à autre, ou vous compactez le tout. non pas à l'aide de compacteur, mais en rusant comme un vieux renard.

Une colonne est une suite de douze sprites portant le numéro 15 dans la table. Le code 56 correspond à cette colonne. Ainsi, vous gagnez 11 octets par colonne, sachant tout de même qu'il y aura un bon paquet de petits programmes qui se chargeront d'afficher les divers éléments de votre jeu. C'est un travail de titan mais. croyez moi, le résultat vaut vraiment la peine que vous vous serez donnée.

Un dernier conseil, travaillez avec beaucoup de patience, sinon vous allez très rapidement vous trom"er avec un jeu sans âme et des salles se ressemblant trop pour être crédibles.

PREMIEREMENT, LES SPRITES TURBO

Je vous ai donné un bon paquet de routines d'affichage pour vos sprites. Il n'empêche que je gardais la meilleure, la plus belle, la plus gourmande en mémoire, la plus rapide, la plus astucieuse pour la fin. Cette routine vous permettra l'affichage de sprites deux fois plus gros que d'habitude. Je devais lui trouver un nom, c'est ainsi que les cinq lettres TURBO me sont venues à l'esprit.

Dans toutes les routines précédentes, nous étions face à un programme affichant des octets à l'écran. Avec la méthode TURBO, nous n'affichons rien à l'écran mais créons un programme hyper speed . qui s'occupera de cette tâche. Il fallait le faire, mais surtout y penser. Ce qui suit est bien évidemment optimisable car ce qui compte pour moi est de vous en donner le principe, le reste ne regarde que vous.

LD A,12
LD (50231),A

Voilà le principe. Pour chaque octet du sprite, nous allons générer ces deux lignes assembleur. Une fois l'ensemble créé, il sera exécutable, comme sur une autoroute, sans boucle et sans accroc. En deux mots, plus rapide tu meurs, et faire plus gourmand en mémoire me paraît également difficile. Notez que le programme ci-joint peut aisément être modifié pour ne pas afficher la matrice du sprite sous forme de rectangle, mais seulement les octets différents de zéro.

Le comble est qu'en améliorant la routine, non seulement nous ne perdons pas en vitesse, mais au contraire: nous en gagnons car le source ainsi généré sera plus court, donc plus rapide à l'exécution.

Ne vous affolez pas à la vue du programme générateur. Il est lent, voire très lent, mais personne ne vous demande de faire une animation de 50 ou 25 images seconde, mais une animation fluide sans accroc. Alors n'hésitez pas, calculez tranquillement le prochain programme affichant votre sprite, synchronisez-vous avec le balai écran et lancez les turbos, l'affaire sera dans le sac.

UN TURBO,
COMMENT CA MARCHE

Parlons d'abord de code désassemblé. LD A,&45 se traduit par &3E suivi de &45. LD (&C000), A se traduit par &32,00,&C0. Cela fait 5 codes dont deux sont connus (&3E et &32). Le reste n'est que calcul. On prend les octets du sprite dans l'ordre de l'affichage. Ces valeurs seront placées dans l'accu et passées dans la routine à raide du registre IX qui pointe en permanence dans la future routine.

L'adresse écran est calculée dans HL et comme pour les données, estpassée à la routine à l'aide du registre IX. Le registre B sert de compteur d'octets et de lignes. Après avoir placé un octet, on incrémente l'adresse écran (HL) de un, le pointeur dans la table du sprite (DE) de un et celui pointant dans la routine TURBO (IX) de cinq. En fin de calcul, il ne reste plus qu'à placer un petit &C9 qui n'est autre que le fameux RET qui terminera la routine en beauté. Avouez qu'il est difficile de faire plus simple pour obtenir une tel le vitesse d'exécution.

RIDEAU, DI DIOU

C'est ici que nos routes se séparent . Vous savez comment créer des tableaux pour vos jeux, afficher et déplacer vos sprites, tester les collisions entredivers personnages de votre jeu et optimiser vos programmes en travaillant avec le balai écran. Vous ne voulez tout de même pas que je donne une idée de scénario, non mais. Au boulot et faites mumuse sans compter les heures et encore moins les jours. Il va de soi que nous allons très rapidement trouver une idée de génie pour remplacer cette rubrique, dès le mois prochain. J'avoue avoir ma petIte idée, si elle vous tente écrivez-moi très vite pour qu'elle soit mise sur pied dans le numéro de février.

Mon idée est la suivante, des livres comme les Clefs pour Amstrad et autres bonnes références étant épuisés, que pensez-vous de voir. Ensemble (étalé sur quelques petits mois), l'ensemble des vecteurs système ainsi que les circuits de nos machines favorites? Aussi pour ne pas être trop barbant, que pensez-vous de passer dans cette rubrique de petits programmes Basic (genre les 7 nains) qui ne font rien de spécial? Alors, si vous êtes d'accord avec mon idée, faites-le savoir très rapidement et à vos plumes et claviers.

QUATRIEMEMENT

No comment!

; SPRITE TURBO
; HL = ADRESSE ECRAN
; DE = TABLE SPRITE
; B = HATEUR
; C = LARGEUR
;

CALL CREATE
CALL &BD19
JP TURBO

CREATE LD A,C ; AUTOMODIFIE
LD (LONG+1),A ; LE PROG
LD IX,TURBO
BOUCLE PUSH BC
PUSH HL
LONG LD B,0
BOUCL2 LD (IX+0),&3E ; LD A,(?)
LD A,(DE)
LD (IX+1),A
LD (IX+2),&32 ; LD (??),A
LD (IX+3),L
LD (IX+4),H
INC DE
INC HL
INC IX
INC IX
INC IX
INC IX
INC IX
INC IX
DJNZ BOUCL2
POP HL
CALL &BC26
POP BC
DJNZ BOUCL1
LD (IX+0),&C9
RET

TURBO DEFS 5*LARGEUR*HAUTEUR+1

A100% n°33, Janvier 1991 p56-57

★ ANNÉE: 1990
★ AUTEUR: Alain Massoumipour

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

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

Lien(s):
» Coding » De l'Arcade de l'Action n°29
» Coding » De l'Arcade de l'Action n°32
» Coding » De l'Arcade de l'Action n°30
» Coding » De l'Arcade de l'Action n°28
» Coding » De l'Arcade de l'Action n°31
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 437 millisecondes et consultée 1983 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.