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 : GFA Basic - ViewPort
(Article écrit par Max et extrait d'Amiga News Tech - juin 1989)
|
|
Alors, il avance, ce jeu ? Ah, vous avez encore quelques problèmes... Qu'à cela ne tienne, cette troisième
et dernière partie de notre (petite) initiation au GFA Basic devrait vous aider à y voir plus clair.
J'en devine certains, au fond de la classe, qui se demandent à quel jeu je peux bien faire allusion. Alors
pour les attardés et/ou les petits nouveaux, je rappelle que Micro-Application et Commodore Revue (c'est nous !)
ont lancé, à l'occasion du GFA Basic sur Amiga, un petit concours doté de prix sympathiques. Le but est
de réaliser, entièrement en GFA, un petit jeu quelconque, exploitant les capacités tant de l'Amiga que du
GFA Basic. Pour vous aider, et compte tenu de la nouveauté de ce langage, nous publions depuis maintenant
trois mois une mini-initiation au GFA, destinée à vous aider à mettre vos idées en forme. Non, non, ne nous
remerciez pas, c'est tout naturel, voyons.
Si ma mémoire est bonne, vous avions vu en détail toutes les
instructions graphiques que le GFA Basic possède :
dessins géométriques quelconques, mais également sprites, BOB, etc. Mais, vous vous en doutez certainement, ce
n'est encore pas suffisant. Il va falloir maintenant nous intéresser de plus près à l'organisation de l'écran -
au sens large du terme - pour pouvoir le bidouiller quelque peu.
Le ViewPort
Sans trop vouloir entrer dans les détails, le ViewPort n'est rien d'autre que le coeur de tout
écran Intuition : il s'agit d'une structure de 40 octets, dans laquelle on trouve les différentes
particularités de l'écran correspondant (mode, couleurs, etc.). Ce ViewPort va nous servir dans notre jeu,
car Intuition possède plusieurs fonctions qui lui sont consacrées, la plus intéressante pour nous,
étant bien entendu le défilement.
Pour obtenir l'adresse du ViewPort de notre écran, il suffit d'employer la fonction SCREEN(x),
où "x" est le numéro de l'écran dont on recherche le ViewPort. Par exemple :
OPENS 1
viewport%=SCREEN(1)+44
|
...et la variable viewport% contiendra l'adresse du ViewPort de notre écran.
Qu'allons-nous donc en faire ? Je vous rappelle que GFA Basic met à notre disposition toutes
les fonctions des bibliothèques Intuition les plus utilisées, sans passer par des bibliothèques
sans fin, comme c'était nécessaire en AmigaBasic. Dans le cas présent qui nous préoccupe,
les fonctions de la graphics.library vont nous être utiles. Et je le prouve, sans plus tarder :
Void ScrollVPort(vport%,delatx&,delaty&) où "vport%" est donc l'adresse de la structure
ViewPort de notre écran, "deltax&" et "deltay&" les valeurs horizontales et verticales
(respectivement) du défilement, exprimées en pixels.
Ainsi, le programme suivant :
...commence par ouvrir un écran, puis dessine un cercle rempli en son centre, pour enfin
décaler cet écran (de manière assez fluide, il faut le reconnaître) jusqu'à disparition
dudit cercle. L'effet peut être amélioré en ajoutant dans la boucle l'instruction VSYNC,
qui attend le retour du rayon de balayage du moniteur.
Comme vous le voyez, cela ne présente aucune difficulté insurmontable (enfin, si, une quand même, comme
nous l'allons voir au prochain paragraphe). Libre à vous maintenant de compléter
l'image au fur et à mesure du défilement, afin de donner un effet de prise de vue en mouvement.
Oui, j'évoquais plus haut, au sein des parenthèses, une difficulté à surmonter : en
cas d'utilisation de BOB (et cela m'étonnerait beaucoup que vous n'en fassiez pas usage),
il vous faudra attendre le moment précis où ils seront tous effacés de l'écran pour défiler
celui-ci, sinon des effets secondaires... heu... disons inesthétiques risquent d'apparaître.
Cela implique donc une synchronisation très fine et aucune perte de temps dans le programme.
A moins d'utiliser une technique particulière connue sous le nom de double tampon mémoire.
Double tampon mémoire
L'idée de base est très simple à comprendre : il s'agit d'utiliser, non pas un écran mais deux,
dont un seul sera bien sûr visible sur le moniteur. Le second écran ne sera en
fait qu'une zone de mémoire servant de tampon ("buffer") et dans laquelle on dessinera toute l'image,
avant de l'afficher sur le moniteur. Le premier écran deviendra à ce moment-là le
tampon, dans lequel on dessinera la prochaine image devant apparaître, et ainsi de suite.
La difficulté consiste ici en l'ouverture des deux écrans, ainsi qu'en l'affichage sur le moniteur
de celui "caché" en mémoire. Bien sûr, un programme du genre :
...simplifierait la tâche, mais vous pouvez essayer, l'effet ne rend pas très bien.
Malgré le fait que les deux écrans aient les mêmes dimensions et la même palette (c'est obligatoire !),
la transition entre les deux reste visible. D'où la seconde méthode qui, bien sûr, élimine
ce problème et présente en plus, l'avantage de consommer (un peu) moins de mémoire.
Pour la mettre en oeuvre, il convient de programmer le Copper, ce coprocesseur qui pilote tous
les processeurs spécialisés de l'Amiga. Pas directement rassurez-vous, nous allons utiliser les
fonctions Intuition prévues à cet effet. Les procédures suivantes résoudront le problème de la
mise en place du double tampon mémoire de l'échange des deux écrans, ainsi que du retour à la
situation normale :
Comment se servir du programme
Présenté tel quel, ce programme ne semble pas très puissant. Pourtant, il l'est ! Voici comment vous
en servir :
- La procédure "make.double" est chargée de réserver une certaine quantité de mémoire, destinée
à héberger les plans de bits du second écran. Il est important de ne l'appeler qu'une seule fois dans
le programme !
- Les procédures "double.on" et "double.off" autorisent et inhibent (respectivement) l'usage du
double tampon mémoire. Ceci peut être utile si vous désirez une page de présentation, ou bien un
tableau des meilleurs scores, qui eux, ne nécessitent pas l'emploi de cette technique.
- La procédure "echange.double" porte bien son nom, car c'est grâce à elle que vous allez
pouvoir échanger les contenus des deux écrans (plus exactement : recopier l'écran 2 dans l'écran 1).
- Et enfin, la procédure "leave.double" restitue au système toute la mémoire utilisée
par le double tampon mémoire.
Utilisées telles quelles, ces procédures ne permettent de gérer qu'un écran de 320x256 en 8 couleurs.
A vous de modifier les valeurs pour un écran d'un autre format (faudrait peut-être que vous
bossiez un peu vous aussi, non ?).
Pour clarifier encore plus les choses, voici un exemple d'utilisation de ces procédures :
Cela n'empêche absolument pas l'utilisation de lutins ("sprites") divers et variés, les effets
de couleurs (palette modifiée sous interruption avec EVERY et AFTER), bref, ce n'est pas le
paradis mais presque.
|
