Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : AMOS - Faites vos jeux (Com-Roid)
(Article écrit par Stéphane Schreiber et Yves Huitric et extrait d'Amiga News Tech - janvier 1991)
|
|
Après le Pac-Man, voici un autre grand classique des jeux vidéo, j'ai nommé Break-Out.
Ou plutôt Arkanoki, puisque ce petit jeu en est fortement inspiré. Contrairement à la dernière fois, où nous
n'avions pas employés AMAL, le langage d'animation sous interruption d'AMOS, Com-Roid l'utilise abondamment
pour la gestion de la balle bien sûr, mais aussi pour tous les autres BOB que l'on a besoin d'afficher. Le
résultat est une animation fluide et hyper-propre avec toutefois une exception, que nous verrons plus loin.
Préparatifs
Mais avant toute chose, vous allez devoir dessiner quelques sprites et icônes à l'aide du
Sprite-Designer pour pouvoir profiter de ce génial programme. Voici donc la composition des banques
utilisées :
| Numéros |
Tailles |
Définition |
| 1 |
16*8 |
La balle |
| 2 |
32*8 |
La raquette |
| 3 à 8 |
32*32 |
Animation de l'explosion de la raquette |
| 9 |
16*16 |
Motif de remplissage pour le fond |
| 10 à 14 |
16*8 |
Animation de la disparition des briques |
Note : placez le "hot-spot" (point chaud) de chaque sprite en son centre.
Banque Icônes "ComRoid_lcones.ABK" - sept icônes en 32 couleurs.
| Numéros |
Tailles |
Définition |
| 1 à 7 |
16*8 |
Les sept types de briques
(le type 7 est indestructible) |
Vous aurez également besoin de copier depuis les disquettes originales d'AMOS, dans le
répertoire "Samples", le fichier Boom.ABK en le renommant en "ComRoid_Sample.ABK".
Enfin, dessinez-vous sous Deluxe Paint un écran de jeu en 320x256 et 32 couleurs, comportant
sur sa droite le panneau de contrôle (score, nombre de vies, etc.). La fenêtre de jeu,
quant à elle, va des coordonnées (8,8) à (228,242). Compactez cet écran et sauvez-le sous
forme de banque, grâce aux quelques lignes suivantes :
A noter pour les fainéants de nature qu'ils pourront s'esbaudir devant les talents de graphiste
de notre vénéré rédacteur en chef en achetant la disquette que nous n'allons pas manquer de
mettre en vente incessamment sous peu.
Le tableau
La définition du tableau est stockée dans... ben, dans le tableau "LEVEL" (ligne, colonne).
Chaque brique mesurant 16 pixels de large et la bordure de la fenêtre de jeu mesurant, quant à elle,
8 pixels sur 8 de haut, on en déduit que les coordonnées écran d'une brique sont obtenues par les formules :
- x_écran = 8+(colonne*16)
- y_écran = 8+(ligne*8)
On s'en servira dans la procédure DISPLAY_LEVEL lorsque l'on dessinera le tableau.
A l'inverse, les coordonnées-tableau d'une brique à partir de ses coordonnées écran sont
calculées grâce aux formules :
- colonne = (x_écran-8)/16
- ligne = (y_écran-8)/8
Mais pourquoi donc se masturber les neurones à café à rechercher les coordonnées-tableau
d'une brique à l'écran ? Tout simplement pour savoir si la balle a rencontré une brique ou non !
Car en effet, nos briques sont affichées sous forme d'icônes (memory bank 2 en AMOS) et
qu'il n'existe aucun moyen de détecter les collisions icône/BOB (et inversement). Cela nous
oblige donc à quelques galipettes, dont on se serait quand même bien passé :
récupération des coordonnées-écran de la balle, conversion en coordonnées-tableau et vérification de
la présence ou non d'une brique à cet endroit.
Si ce test est positif et si la brique n'est pas indestructible (autrement dit, si LEVEL(colonne,ligne)
est supérieur à 0 et inférieur à 7), on commence par effacer la brique au moyen de l'instruction
"BAR", puis on affiche au même endroit le BOB numéro 3 dont l'animation symbolise la disparition
de la brique. Un petit coup de "Rnd" par-dessus tout ça pour décider si une pastille-bonus
doit apparaître, et on inverse finalement la direction de la balle. Remarquez que cette inversion
est brutale un bon casse-brique moderne se devrait d'effectuer quelques tests supplémentaires pour
décider le plus précisément possible dans quelle direction la balle doit repartir, en fonction de
son point de collision avec la brique.
C'est d'ailleurs à ce moment-là que se produit un petit effet visuel assez désagréable : comme on
est en double tampon mémoire, l'instruction "BAR" agit en fait deux fois, d'abord dans l'écran
physique puis dans l'écran logique. Les BOB étant automatiquement effacés avant puis réaffichés après,
un petit ralentissement inévitable survient (ou alors, s'il n'est pas inévitable, c'est que j'ai
mal cherché ; pourtant, j'ai passé des heures à m'emm... avec les instructions Autoback et consoeurs,
sans arriver à faire mieux que ça. Si quelqu'un connaît une astuce...).
T'AMAL ou ?
Cinq chaînes d'animation AMAL ont donc été définies : BAL$ s'occupe de la balle, RAQ$ de la raquette,
et BON$ des différents bonus qui tombent. La quatrième, CHRONO$, ne fait rien de visible à l'écran ;
il s'agit là d'une astuce que j'ai repiquée à François Lionet dans son excellente initiation à AMOS :
par défaut, chaque canal AMAL est attribué au sprite matériel de même numéro. Ici, CHRONO$
est défini sur le canal 0, celui du sprite de la souris. Mais comme on n'utilise pas ce sprite, ses
effets ne sont pas visibles à l'écran.
Je trouve ça très rigolo comme manière de procéder.
En l'occurrence, CHRONO$ se contente d'incrémenter un compteur de 0 à 500 avant d'augmenter la
vitesse de déplacement de la balle. L'interruption AMAL se produisant tout les 1/50e de seconde. je
n'ai pas besoin de ressortir tous mes cours de maths de 6e pour calculer que la vitesse de balle
augmente toutes les 10 secondes. A noter que certains préfèrent l'augmenter proportionnellement
au score, mais je trouve cette manière de procéder plus amusante. Chacun ses goûts. Et enfin,
la cinquième chaîne est "statique" : elle définit seulement l'animation (c'est-à-dire la suite d'images)
à utiliser pour le BOB numéro 3.
Quant aux registres globaux d'AMAL (RA à RZ), seuls quelques-uns sont utilisés pour communiquer
des données d'un canal à un autre ; en l'occurrence, les coordonnées de la balle et de la raquette,
la vitesse de la balle et le nombre de bonus en train de tomber.
Perspectives d'améliorations
Oh, bien sûr, il y en a quelques-unes... On n'allait tout de même pas vous mâcher tout le travail,
non ? La première, elle est évidente, est de faire en sorte que les bonus en soient réellement, au
lieu de se contenter de tomber bêtement jusqu'en bas de l'écran. Ils pourraient par exemple augmenter
le score ou donner ces options à la raquette... Deuxièmement, il serait de bon ton de rajouter des
petites bestioles qui feraient qu'à embêter le joueur. Et puis, pourquoi pas, autoriser le jeu à deux,
la continuation de la partie, et que sais-je encore ? Ça n'est qu'une question d'imagination.
|
