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 - Nouveautés de la version 1.2
(Article écrit par François Lionet et extrait d'Amiga News Tech - octobre 1990)
|
|
La version 1.2 est disponible au moment même où vous me lisez, sous la forme d'un programme domaine public qui modifie
votre disquette AMOS. Outre la correction de certains bogues, cette version apporte de nouvelles instructions et
améliorations :
Un meilleur multitâche
La boucle de l'éditeur et du mode direct ont été améliorés pour permettre une meilleure utilisation multitâche,
AMOS ne prend plus tout le temps machine aux autres programmes. En mode programme, vous devrez parsemer votre
programme de l'instruction "Multi Wait ..." qui rend la main aux autres programmes, pendant approximativement un
balayage d'écran. Attention, cette instruction est d'autant plus imprécise que le nombre de tâches est élevé.
Préférez "Wait Vbl" pour synchroniser votre programme. "Multi Wait" est l'idéal pour attendre une option de
menu, ou la pression d'une touche.
Le retourneur de sprites
Il s'agit d'une des principales techniques pour réduire la place mémoire occupée par un programme. Dans un jeu, les
graphismes occupent la majeure partie de la mémoire (avec la musique). Plus un jeu est complexe, plus il faudra de
sprites, et donc de mémoire. En général, le personnage principal peut se diriger dans toutes les
directions : gauche-droite pour un jeu à défilement latéral, haut-bas (en général) pour un jeu de tir,
et même dans tous les sens. Le personnage principal est aussi le mieux animé.
Tout ceci fait que la banque de sprites d'un jeu est principalement constituée des phases d'animation
du personnage principal dans une direction, puis dans une autre, par simple symétrie des sprites.
Les nouvelles instructions de l'AMOS, permettent une symétrie automatique des sprites. Il suffit
de ne conserver qu'une seule direction dans la banque de sprites.
Le gros problème lors de la programmation de ces nouvelles fonctions, était de conserver la
compatibilité avec la version 1.1. J'ai donc dû ruser : tout se fait par l'intermédiaire du numéro
de l'image à afficher.
Exemple : imaginons que l'image 1 dans la banque de sprites représente un vaisseau spatial dirigé
vers le haut-droite :
- BOB 1,160,100,1 affichera le vaisseau à droite.
- BOB 1,160,100,$8001 fera une symétrie passant par l'axe vertical. Le vaisseau sera pointé en haut à gauche.
- BOB 1,160,100,$4001 fera une symétrie par rapport à l'axe horizontal. Le vaisseau sera pointé en bas
à droite.
- BOB 1,160 1 00,$C001 effectuera les deux symétries précédentes. Le vaisseau pointera en bas à gauche.
Vous avez compris que pour indiquer au générateur de BOB le retournement d'une image, il faut se
servir des bits 15 et 14 du numéro de l'image.
- Bit 15 : symétrie verticale.
- Bit 14 : symétrie horizontale.
Pour ceux que l'hexadécimal rebute, j'ai rajouté trois nouvelles instructions :
- =HREV(image) : symétrie horizontale.
- =VREV(image) : symétrie verticale.
- =REV(image) : double symétrie.
Ces fonctions effectuent une simple addition de respectivement $8000, $4000 et $C000 au numéro de
l'image.
Fonctionnement du retourneur de sprites
Le programme travaille directement dans la banque de sprites, au moment même de l'affichage.
La fonction sprite base (image) ramène une adresse pointant sur la définition d'une image
dans la banque de sprites.
SPRITE BASE: +0 (Mot) (Taille image en X)/16
+2 (Mot) (Taille image en Y)
+4 (Mot) Nombre de plans mémoire
+6 (Mot) Position du point chaud en X
+8 (Mot) Position du point chaud en Y
+10 Premier plan image
+??? Deuxième plan image
...
+??? Dernier plan image
|
Vous pouvez ainsi connaître la taille d'une image avec deek :
A=Sprite Base(1)
Print "Taille en X:";Deek(A)*16
Print "Taille en Y:";Deek(A+2)
|
J'ai utilisé le sixième mot de cette définition pour stocker les drapeaux indiquant le
retournement de l'image. Le bit 15 de la position du point chaud en X indique que l'image
est actuellement retournée en X dans la banque ; le bit 14 a la même fonction en Y.
Imaginons que vous utilisiez l'instruction BOB 1,100, 100, HREV(5).
Au retour de balayage suivant, AMOS inspecte la liste des BOB à afficher. Il trouve l'image $8005.
Il regarde le bit 15 de l'adresse 6 dans la définition de l'image. L'image est dans son état originel,
le bit est à zéro. AMOS appelle donc la routine de retournement en X, et positionne le bit 15 à 1.
Ceci fait, le BOB inversé est affiché normalement à l'écran.
Imaginons maintenant que vous bougiez le BOB, sans en changer la forme : BOB 1,101,100,HREV(5).
Au prochain balayage, AMOS recommence les mêmes opérations. Il trouve encore l'image $8005
à afficher à une autre position. Il inspecte le bit 15 de l'adresse 6 : celui-ci est à 1,
signifiant que cette image est déjà dans le bon sens : AMOS n'a pas besoin de retourner l'image,
d'où un énorme gain de temps !
Cet exemple nous a permis de comprendre le fonctionnement du système, et de voir les avantages
de la méthode utilisée :
- Elle ne nécessite aucun espace mémoire supplémentaire.
- Elle n'effectue les inversions qu'un nombre limité de fois.
Le dernier point n'est plus vérifié si l'on utilise plusieurs BOB
pour afficher la même image :
BOB 1,160,100,$4001
BOB 2,160,100,1
|
A chaque balayage, AMOS retournera une première fois l'image pour afficher le premier BOB, puis
une seconde pour afficher le deuxième ! Imaginez le désastre lorsque la taille des BOB
est importante ou lorsque vous avez une dizaine de BOB en même temps. Il faut donc éviter à tout
prix d'utiliser plusieurs fois une image et sa symétrique en même temps sur l'écran.
Paste Bob et Paste Icon
Le retourneur de BOB est également implémenté pour ces instructions. Pour la deuxième, en l'occurrence,
il s'agit d'un retourneur d'icônes.
Inverser les sprites matériels
Les routines sont totalement automatiques pour les BOB. Pour ne pas trop en alourdir la gestion,
je n'ai pas implémenté le système pour les sprites matériels. On peut cependant l'utiliser par
un moyen détourné. Le retourneur travaille directement dans la banque. Lorsque vous affichez un
sprite matériel par l'instruction SPRITE, AMOS explore la même banque. Si l'une des images est
retournée à ce moment, elle sera affichée tel quel.
Pour résumer, voici comment afficher en SPRITE les quatre symétriques de l'image numéro 2
(notez l'utilisation de Paste Bob en dehors de l'écran pour inverser l'image dans la banque...) :
Attention ! Vous devez être sûr de la position de l'image dans la banque lorsque AMOS calcule les sprites,
faute de quoi le sprite matériel sera affiché aléatoirement.
Les collisions et l'inverseur de BOB
Le problème est exactement le même que pour les sprites matériel. Le programme de collision utilise
la banque d'images dans l'état où elle se trouve au moment de l'instruction. Le programme suivant
ne fonctionnera cas :
Voyons d'où vient l'erreur : au moment du balayage d'écran, AMOS commence par dessiner le BOB
numéro 1. L'inverseur d'image remet donc l'image dans le sens originel. Puis AMOS appelle de nouveau
l'inverseur pour dessiner le symétrique en X et en Y. Vient l'instruction Collide. Elle ne
fonctionnera pas correctement, car nous lui demandons de détecter une collision entre l'image 1
de la banque et son inverse. Or, à ce moment précis, seul l'inverse se trouve dans la banque !
Collide fera ce qu'elle pourra, et détectera les collisions entre les deux inverses. Le résultat
de la détection de collision sera donc erroné !
Une conclusion s'impose : il ne faut jamais essayer de détecter les collisions entre une image
et son inverse. Ou mieux, la détection de collision entre images inversées n'est valable que si
un seul BOB utilise l'image à ce moment.
AMAL et l'inverseur de BOB
Afin d'autoriser l'utilisation du "retourneur", j'ai implémenté l'hexadécimal en AMAL. Vous pouvez
donc maintenant taper n'importe quel chiffre sous les deux formes.
Exemples d'adaptations : AMAL 1,"Anim 0,(1,2)(2,2)(3,2)(4,2)" devient
AMAL 1,"Anim 0,($C001,2)($C002,2)($C003,2)($C004,2)" pour une inversion en X et en Y.
N'essayez pas de modifier le compteur d'une boucle, faites plutôt le changement au moment de
l'affectation de la valeur à l'image. Exemple : AMAL 1,"For R0=1 To 10; Let A=R0; Next R0"
devient AMAL 1,"For R0=1 To 10; Let A44000+R0; Next R0".
Inverser les blocs
Ayant fait les routines de symétrie de BOB, il m'était très facile de faire deux nouvelles
instructions pour renverser les blocs : HREV BLOCK numéro fait une symétrie horizontale.
VREV BLOCK numéro fait une symétrie verticale ou numéro désigne le bloc.
BANK SWAP Bank1, Bank2
Cette nouvelle instruction échange deux banques mémoire entre elles. Vous pourrez ainsi avoir plus
d'une banque d'images dans un programme ; échanger une banque de sprites et d'icônes ; avoir
plusieurs musiques.
=DEV FIRST$("filtre")
=DEV NEXT$
|
Ces deux instructions fonctionnent de la même manière que DIR FIRST$("")
et DIR NEXT$, mais elles retournent les noms des périphériques logiques (autrement dit des lecteurs
de disquette) branchés sur votre Amiga. Pour obtenir le nom réel, vous devez supprimer les
espaces à l'aide de la soustraction de chaînes. Exemple :
La version 1.2 est en même temps un peu plus petite que la précédente : deux ko de
précieuse mémoire en plus, ça aide.
|
