Différences

Ci-dessous, les différences entre deux révisions de la page.

--- back2root:archives:jeu-de-role-en-gfa-basic:02-editez-vos-cartes-graphiques [2025/06/11 18:19] – frater
+++ back2root:archives:jeu-de-role-en-gfa-basic:02-editez-vos-cartes-graphiques [2025/06/12 00:09] (Version actuelle) – [Programme Complet] frater
@@ Ligne 1: / Ligne 1: @@
-===== 02 - Editez vos cartes graphiques =====
+===== 02 - Éditez vos cartes graphiques - WIP =====
+==== Editer vos cartes graphiques ====
 La programmation d'un jeu de rôle façon Ultima passe par la réalisation d'un éditeur capable de définir la carte d'un monde médiéval fantastique.
@@ Ligne 5: / Ligne 7: @@
 ==== Notions de base ====
-Dans les jeux de rôle de type Cfrimer-ou Aentarsy (hste non lemitanive},
+Dans les jeux de rôle de type Ultima ou Fantaisy (liste non limitative), le joueur gère les actions d'une équipe de personnages. Celle-ci se déplace sur une grande carte représentant l’ensemble du monde de jeu. Seule une partie de la carte est affichée à l'écran. C’est une sorte de fenêtre de visualisation qui se déplace sûr là carte totale. Lorsque que les personnages se déplacent, la fenêtre montre une nouvelle position.
-le Joucur gére les actions d'uné équipe de personnages. Celle-ca
-se déplace sur une grande carte réprésentant l’ensemble du monde de
-jeu. Seule une partie de la carte est affichée à l'écran. C’est une sorre
-de fénêtre de visualisation qui se déplace sûr là carte totale. Lorsque
-ilï_!!:i pPÉrsUnnages e ljl'l:i.'!ll‘:l.-:.'-l:l'.l'l..l IJ. funÈtru IMCHIÈTE ]i]. []ULI".-'-L‘HI_‘ ]."U'.iiliüîl.
 ==== Dessin de la carte ====
-L'univers de jeu doit être vaste pour que le joueur ait le plaisir de
+L'univers de jeu doit être vaste pour que le joueur ait le plaisir de l'explorer. Cela nous empêche de stocker le dessin de la carte sous la forme d'une image, pour des raisons de place mémoire. une image de 320x220 pixels en basse résolution occupe 32 Ko. Une image de 1600x800 pixels, équivalent à un espace de 5x4 images écrans, occupe une place mémoire de 640 Ko. C'est beaucoup trop pour un 520 ST et même pour un 1040 ST, en tenant compte de la taille prise par le programme et les autres données graphiques.
-l'explorer. Cela nous empêche de stocker le dessin de la carte sous la
-fi':lr'rnf: ll'l.":l'll'l[Ï 'il_l'_l.:li_:_f".l l‘.li‘.-lfl' llll.'Ë"'. mis-;nn:—: I:]fl Fli-fll'_'l.'f mémuir&. .[.l-!'llË ['l'l'".'ii":_"f
-de 3X0x220 pixels en basse résolution occupe 32 Koo Une image de
-1600800 pixels, équivalent à un espace de 5x4 images écrans, occupe
-une place mémoire de 640 Ko. C'est beaucoup trop pour un 520 5T
-et même pour un 1040 5T, en tenant compté de la taille prise par le
-programme ot les autres données graphiques
 ==== Dessin avec éléments graphiques de base ====
-YA l.'iliiLl. I.]I_I !':ZLI'_PL'l:'i.EI.' |-.5I:]..-Ii_:l"-I: L:II'_' IH. carie Cil ].HIËIËI'I.E]'LIII-J"I::. Ch J_.i'-l:'LIL J.-'-.'I. I'L‘L'IEE:UI.'
+Au lieu de stocker l’image de la carte en mémoire, on peut la redessiner avec des éléments de base. Une foret peut être dessinée avec 6 ou 7 éléments, une rivière ou un plan d'eau n'ont pas non plus besoin de de beaucoup d’éléments différents. A la rigueur, une forêt peut être dessiné avec une seule petite image représentant un arbre, et la montagne avec un seul élément représentant la silhouette d'une cime. c'est le procédé utilisé par bon nombre de logiciels de jeu du commerce. Pour des raisons techniques qui tiennent plus à l'organisation des mémoires vidéos, les éléments ont le plus souvent une taille de lôx16 pixels ou 32x32 pixels.
-ner avec des élements de basé. Une foret peut étre dessinée avec A ou
- {.:'Ii'l:ml_'“['ltil TEFIë |_i"-"ill=“|1l;': CHI] LETI l-.l:l‘r'l'l'l. I.'.ll['.fil] r:"nnt 'l-.l.'l."'. T l'l]'ll':l l."ËË'i-ÜE]'l
+Une carte est alors mémorisée sous la forme d'une liste d’éléments graphiques. On peut stocker cette liste dans un tableau numérique à deux dimensions, dont le type dépend du nombre d'éléments possibles. Avec moins de 256 éléments, ce qui est déjà énorme, on peut utiliser un tableau de type BYTE (symbole |), chaque élément du tableau n'occupant qu'un octet en mémoire.
-de beaucoup d'élemonts différents. A la ngucur, une foréc peut S
-dessine avec une seule petite image représentant un arbré, et la montagne
+Avec des éléments de 16x16, une carte de 1600x800 pixels peut être stockée dans un tableau de 100x50 cléments, occupant une place mémoire de 5000 octets. Sa déclaration se fait de la manière suivante:
-avec un seul élément représentant la silhouerre d'une cime.
-(st le procédé utilisé par bon nombre de logiciels de jeu du com-
+<code freebasic>
-FICFce, Pl"l'l_l:l" I::Il:_"; |_..|.i::i|:.;'r'.:'i li_'i;hrli:.[ul;'i L]'L'l.i Li:l_'l'II-II:Tll: El. l’rjrg:hni!-:ati:m I.:Il_':'i
+OPTION BASE 1
-mémoires vidéos, les elements ont le plus souvent une taille de
+DIM carte|(100,50)
-lôx16 pixels ou 32x32 piæels,
+</code>
-Une carte esr alors mémorisée sous la forme d'une lisre d’éléments
-Ë'l'“..'l.'l:lhiqüfl_:j I:::!Il'l TËL[E ._"'Îl'.l:'ll'_'l'i.::l- LECLE [i:-:.L-: ijfiflfi 11F Ï.EIZ_J.IOE'LI. rlurrïrl:riqu:_' ä.
+L'instruction ''OPTION BASE 1'' force le basic à numéroter ces tableaux à partir de l’indice 1 et non 0. Pour calculer le gain de mémoire entre les deux méthodes, il faut prendre en compte la place mémoire prisé par les éléments graphiques.
-deux dimensions, dont le type dépend du nombre d'éléments possibles.
-Avec moins de 256 élements, ce qui est déjà énorme, on peur
+Un élément graphique de 16x16 pixels stocké dans une variable alphanumérique grâce à l'instruction ''GET'' occupe une place de 134 octets, ce calcul ayant été fait avec l'instruction ''LEN'' qui détermine la taille d'une variable alphanumérique.
-utiliser un tableau de vvpe BYTE (svmbole |), chaque élément du tabléau
-n'occupant qu'un bctét én mémoire.
+<code freebasic>
-Avec des éléments de 16x16, une carte de 1600x8C0 pixels peut être
-stockée dans un tableau de 100x50 cléments, occupant une place
-mémoire de 5000 octets. 5a déclaration se fait de la manière suivante:
-OFTION BASE 1
-DIM carte|{100,50)
-L'instruction OPTION BASE ! foree le basic à numérotér ces tableaux
-à partir de l’indice 1 et non & Four calculer le gain de mémoire enrre
-les deux méthodes, il faur prendre en compre la place mémoire
-prisé-par les éléments praphigues. ;
-Un élément graphique de 16x16 pixels stocké dans une variable alphanumérique
-grâce à l'instruction GET occupe une place de 134 nc
-ters, ce caloul ayant ête fait avec l'instruction LEN qui détermine la
-raille d'une variable alphanumérique.
 GET 1,1,16,16,varf
 PRINT LEN(vars)
-L’expérience montre que l'on peut dessiner des cartes complètes avec
+</code>
-bien moins de 200 éléments différents. Clest donc une valeur limite
-accéptable pour fairé quelques calculs. Vous utiliserez certainement
+L’expérience montre que l'on peut dessiner des cartes complètes avec bien moins de 200 éléments différents. C'est donc une valeur limite acceptable pour faire quelques calculs. Vous utiliserez certainement moins de 200 élements pour créer vos propres cartes. Pour la petite histoire, les premiers jeux Ultima ont été dessinés avec seulement quelques dizaines d'éléments. Le stockage de 200 éléments graphiques prend 26800 octets.
-moins de 200 clements pour créer vos propres cartes. Pour la perite
-histoire, les premiers jeux Ultima ont été dessinés avec seulement
+<code freebasic>
-quelques dizaines d'éléments. Le srockage de 200 éléments graphiques
-prend 26800 oététs.
 DIM element$(200)
-En additionnant la place prise par le codage de la carte t par 200 éle
+</code>
-ments graphique, on arrive à un total de 31800 ocrets (5000+
-), Dans notre cas particulier, le gain de place apporté par le-codage
+En additionnant la place prise par le codage de la carte t par 200 élements graphique, on arrive à un total de 31800 octets (5000+26800), Dans notre cas particulier, le gain de place apporté par le codage de la carte est de 20, mais s'améliore considérablement si la carte est plus grande que 100x50 cléments ou si le nombre d'objets graphique est plus petit que 200.
-de la carte est de 20, maus saméliore considérablement a1 la carte
-est plus grande que 100x50 cléments ou s1 le nombre d'objets gra
-phique est plus petic que 200.
+Cette technique offre un gros avantage pour le développement d'un logiciel: la carte est facile à dessiner une fois que les éléments de base sont créés.
-Cetté téchnique offre un gros avantage pour le développement d'un
-logiciel: la carte est facile à dessiner une fois que les éléments de base
+Même un non-graphiste peut réaliser une jolie carte à partir de beaux éléments de base.
-SONt CTÉES.
-Même un non-graphiste peut réaliser une jolie carte à partir de beaux
-éléments de hase.
 ==== Dessin de la carte Ultima ====
-La portion de carte affichée par les jeux Ultima à une dimension de
+La portion de carte affichée par les jeux //Ultima// a une dimension de 176x176 pixels, et se constitue de 11x11 éléments de 16x16 pixels.  La position de l'équipe de personnages est visualisée par une silhouette en noir affichee au milieu de l'écran.
-x176 pixels, et est constitué de 11x11 clements de 16x16 pixels.
-La position de l'équipe de personnages est visualisée par une silhouerte
-en noir affichee au milieu de l'écran.
-Lors des déplacements, l'image de la carte est redessinée de manière à
-cé que l'équipe soit toujours au centre de l'image visible,
-==== Programmation d'un système de déplacement style Ultima ====
-Pour réaliser un systéme de déplacement similaire à celui d'Ultima
+Lors des déplacements, l'image de la carte est redessinée de manière à ce que l'équipe soit toujours au centre de l'image visible.
-en GEA Basic, il faut résoudre un certain nombte de problémes techniques.
-Nous avons déjà vu que le codage de la carte peur être stocké
+==== Programmation d’un système de déplacement style Ultima ====
-dans un tableam numérique et les éléments graphiques de base dans
-un tabléau alphanumérique, mais il reste bien des questions à etudier.
+Pour réaliser un systéme de déplacement similaire à celui d'//Ultima// en //GFA Basic//, il faut résoudre un certain nombre de problèmes techniques. Nous avons déjà vu que le codage de la carte peut être stocké dans un tableau numérique et les éléments graphiques de base dans un tableau alphanumérique, mais il reste bien des questions à étudier. Comment est-ce que les éléments graphiques sont stockes dans le tableau alphanumérique? Comment afficher rapidement là carte
-Comment est-ce que les éléments graphiques sont stockes dans
+aussi bien sur un STF que sur un STE? Comment stocker les différentes données sur disque? Comment gérer les déplacements de l'équipé sur la carte?
-le tableau alphanumérique? Comment afficher rapidement là carte
-aussi bien sur un STF que sur un STE? Comment stocker les différéntes
+Toutes ces questions sont trop difficiles à gérer dans un seul article, c'est pourquoi ce texte est séparé en deux parties: la première est consacrée à la création d'une carte et la seconde traite de son utilisation pour gérer les déplacements de l'équipe.
-données sur disque? Comment gérer les déplacements de
-l'équipé sur la carte?
+==== Définition des éléments graphiques ====
-Toutes ces questions sont trop difficiles à gérer dans un seul article,
-c'est pourquoi ce texte est séparé en deux parties: la première est consacrde
+On suppose que les éléments graphiques de base ont été dessinés par un graphiste avec un logiciel de dessin type //Degas Elite// où équivalent. Nos précieux éléments sont donc stockés sur disque dans une image au format //Degas//, Le programme ''GENELEM,GFA'' lit l'image //Degas// ''ELEMENTS.P11'' et stocke les éléments graphiques dans un fichier binaire ''ELEMENTS.BIN'' réutilisable par un autre programme.
-à la créition d'une carte et la seconde traite de son utilsation
-pour gérer les déplacements de l'équipe,
+La structure du fichier binaire est la suivante: 32 octets contenant la palette de couleur des éléments graphiques, un octet unique contenant le nombre d’éléments du fichier et le codage des éléments, chacun occupant 134 octets. La position (x,y) des éléments sur l'image est définie dans une série de DATA à la fin du programme, la fin des données étant signalé par la valeur -l
-Définition des éléments graphiques
-On suppese que les éléments graphiques de base ont êté dessinés par
+<code freebasic>
-un graphiste avec un logiciel de dessin type Degas Elite où equivalent.
+' ******************************
-Nos précieux cléments sont donc stockes sur disque dans une
+' * GENÉRATEUR FICHIER BINAIRE *
-image au format Degas, Le programme GENELEM,GFA lie l'image Degas
+' *    ELEMENTS GRAPHIQUES     *
-ELEMENTS.P11 et stocke les éléments graphiques dans un fichier
+' ******************************
-binaire ELEMENTS . BIN réucilisable par un autre programme.
+RESERVE 100000
-La structure du fichier binaire est la suivante: 32 ocrets contenant la
+DIM element$(200)
-palette de couleur des éléments graphiques, un oot unique conténant
+nb_elements%=0
-le nombre d'élements du Hehier et le codage des éléments, chacun
+palette$=SPACE$(32)
-oecupant 134 octets. La position (x,y) des éléments sur l'image
+'
-est définie dans une série de DATA à la fin du programme, la fin des
+@load_dzgas("ELEMENTS.PI1")
-données étant signalé par la valeur -l
-|l HRL NR S A RN
-| * GENÉRATEUR FICHIER BINAIRE *
-HM ELEMENTS GRAPHIQUES #
-LRNF RE RR E RE e e
-RÉSERVE 100000
-DIM element${200)
-nb elements“%=0
-palette$=SPACE4(32)
-Bload dégas("ELEMENTS.PI1*)
 @saisie_elements
-@sauve elements({"ELEMENTS.BIN")
+@sauve_elements({"ELEMENTS.BIN")
 END
-e e 44 E RE W W E R W R R
+'
-* CHARGEMENT-IMAGE *
+' ******************************
-= DEGAS ELITE 8
+' * CHARGEMENT IMAGE           *
-E T T R P e e T o E E S
+' *    DEGAS ELITE             *
-FRAR N A r L AR ARk AR *
+' ******************************
-* La palette est stockée dans la ”
+'
-* variable globale palettes ,j
+' **********************************
-UR RIRF REN RN R Rk RE É RE
+' * La palette est stockée dans la *
-PROCEDURE !oad degas(nom$)
+' * variable globale palette$      *
-palettef=SPACE4(32)
+' **********************************
-OPEN "T",#1,nom$
+PROCEDURE load_degas(nom$)
-SEEK #1,2 .
+  palette$=SPACE$(32)
-BGET #1 VARPTR(palette$}),37
+  OPEN "1",#1,nom$
-VOID XE10S(6,L-VARPTR(palette*))
+  SEEK #1,2
-BGET #1,XB105{2},3#000
+  BGET #1,VARPTR(palette$),32
-CLOSE #l
+  VOID XBIOS(6,L:VARPTR(palette$))
-RETURR
+  BGET #1,XBIOS(2),3#000
-B o e E T e b É el RE
+  CLOSE #l
-* GENERATION FICHIER BINAIRE *
-“ ELEMENTS GRAPHIQUES &
-d e e N AI E R RE N A
-PROCEDURE sauve elements{fichier$)
-LOCAL 1%
-OPEN "o",#1,Tichier}
-BPUT #1,VARPTR(palettet),32
-OUT #1,nb elements®
-FOR i%=1 TO nb elements“
-BPUT #1 ,VARPTR(element5(15)},154
-MEXT i%
-CLOSE #1
 RETURN
+'
-N T e RR E R P PR L TR R E o e R T
+' **********************************
-i CHARGEMENT DES %
+' * GENERATION FICHIER BINAIRE     *
-* ELEMENTS GRAPHIQUES *
+' * ELEMENTS GRAPHIQUES            *
-C e RE e dc d PE E E e E A R E R RS
+' **********************************
-PROCEDURE saisi E__El ements
+PROCEDURE sauve_elements{fichier$)
-LOCAL ns
+  LOCAL i%
-LOCAL px%, pyi
+  OPEN "o",#1,fichier$
-LOCAL px2%,py2%
+  BPUT #1,VARPTR(palette$),32
-nE=0
+  OUT #1,nb_elements%
-RESTORE def elements
+  FOR i%=1 TO nb_elements%
-g
+    BPUT #1 ,VARPTR(element$(1%)},134
-READ px%
+  NEXT i%
-EXIT IF pai==1
+  CLOSE #1
-READ pys .
-INC n
-pxé4a=px=+ls
-pyess=pystis
-GET px%,py¥,px2%,pye%,elemants(n%)
-LOOP
-nb_élémentss=n
-ATARI MAGAZIME m BEST OF GRA BASIC
 RETURN
-| HLJNE SREE
+'
-i POSITION DES n
+' **********************************
-! * ÉLEMENTS GRAPHIQUES *
+' * CHARGEMENT DES                 *
-| ETEN eE ol e o R E
+' * ELEMENTS GRAPHIQUES            *
-def elements:
+' **********************************
+PROCEDURE saisie__elements
+  LOCAL n%
+  LOCAL px%, py%
+  LOCAL px2%,py2%
+  '
+  n%=0
+  RESTORE def_elements
+  DO
+    READ px%
+    EXIT IF pa%=-1
+    READ py%
+    INC n%
+    px2%=px%+15
+    py2%=py%+15
+    GET px%,py%,px2%,py2%,element$(n%)
+  LOOP
+  nb_elements%=n%
+RETURN
+'
+' *********************************
+' * POSITION DES                  *
+' * ÉLEMENTS GRAPHIQUES           *
+' *********************************
+def_elements:
 DATA 1,1
 DATA 18,1
@@ Ligne 187: / Ligne 149: @@
 DATA 52,1
 DATA 69,1
-DATA 66,1l
+DATA 86,1
 DATA 1,18
 DATA 18,18
@@ Ligne 194: / Ligne 156: @@
 DATA 69,18
 DATA -1
-Programme EDITCART
+</code>
-Le programime EDITCART est un éditeur de carte virtuelle écrit entiérement
-en (FEA Basié: Tl sauve les cartes éditées dans des hchiers binaires,
+==== Programme EDITCART ====
-pouvant être relus et exploités par d'autrés programmes.
-Ses fontions sont: lecture d’une carte à partir du disque, sauvegarde
+Le programime EDITCART est un éditeur de carte virtuelle écrit entièrement en //GFA Basic//. Tl sauve les cartes éditées dans des fichiers binaires, pouvant être relus et exploités par d’autres programmes.
-de la carte courante sur disque, déplacement sur la carte, modification
-d'un élément quelconque de la carte, sélection d'un élément
+Ses fonctions sont: lecture d’une carte à partir du disque, sauvegarde de la carte courante sur disque, déplacement sur la carte, modification d'un élément quelconque de la carte, sélection d'un élément graphique, affichage d'une boîte d'informations et option pour quitter le programme. Le tout est entièrement géré à la souris.
-sraphique, affichage d'une boîte d'informations et aption pour quitter
-lc programme. Le tout est entiérément géré à la souris,
+Attention: l'éditeur à besoin d'un fichier d’éléments graphiques pour fonctionner. Exécutez le programme ''GENELEM'' avant d'utiliser ''EDITCART''. Le nom du fichier d’éléments graphiques est ''ELEMENTS.BIN'' par défaut, mais vous pourrez le modifier dans le code source d'EDITCART, ou ajouter une fonction permettant de charger n'importe quel fichier d'éléments graphiques.
-Attention: l'éditeur à besoïn d'un fichier d’éléments graphiques pour
-foncrionner. Exéeutéz le programme GENELEM avant d'utiliser EDITCART.
+==== La simplicité n'est pas de ce monde ====
-Le nom du fichier d'élements graphiques est ELEMENTS.BIN
-par défaur, mais vous pourrez le modifier dans le code source
+Initialement, cet éditeur a Été conçu pour être simple à utiliser et à comprendre. Hélas, il s'est avéré impossible d'écrire des routines d’affichages simples et performantes aussi bien sur STE que STF [dommage que tous les ST ne soient pas dotés de blitter). Les routines d'affichage de EDITCART utilisent donc des techniques de programmation un peu complexes à comprendre pour un programmeur debutant.
-d'EDITCART, ou ajouter une fonction permettant de charger n'imparte
-quel fichier d'éléments graphiques.
+==== Un système d’affichage simple ====
-La simplicité n'est pas de ce monde
-Initialement, cet éditeur a Été conçu pour être simple à utiliser et à
+La première méthode qui vient à l'esprit est de ré afficher entièrement l'écran après chaque déplacement. Dans l’exemple qui suit, le codage de la carte est stocké dans le tableau //CARTE|()// et les éléments graphiques de base dans le tableau //ELEMENT$()//. La procédure //aff_carte// dessine la carte sur l'écran.
--:-:-mprr:nfln:. Hélas, il s'est averé impossible d'écrire des routines d’affichages
-simples et performantes aussi bien sur STE que STF [dommage
+La position du morceau de carte visible par rapport à la carte virtuelle cst contenu dans les variables //ligne_carte// et //colonne_carte//.
-que tous les ST ne soient pas dotés de blitter). Les routinés
-d'affichage de EDITCART utilisent donc des techniques de programmation
+En mettant //ligne_carte// et //colonne_carte// à 1, le côté haut gauche de la carte est affiche sur l'ecran.
-un peu complexes à comprendre pour un programmeur
-debutant.
+Pour déplacer la carte d’une position vers la droite, il faut incrémenter la variable //colonne_carte// de 1 et appeler de nouveau //aff_carte//.
-Un système d’affichage simple
-La première méthode qui vient à l'esprit est de réafficher entiérement
+Pour déplacer la carte d'une position vers le bas, il faut incrémenter //ligne_carte// et exécuter //aff_carte//.
-l'écran après chaque déplacement. Dans l’evemple qui suit, le
-codage de la carte est stucké dans le tableau CART E|() et les éléments
+Remarque: la position (1, 1) correspond au premier indice du tableau contenant la carte, grâce à l’instruction OPTION BASE 1 Sans celle-ci, le premier indice du tableau a la position (0,0).
-graphiques de base dans le tableau ELEMENTS(). La procedure
-Gaff carte dessine la carté sur l'écran.
+Le morceau de carte visible est affiché à l'écran à la position définie par les variables xcarte% et ycarte%. Etant donné là structure interne de la mémoire vidéo et la manière dont fonctionnent les instructions graphiques du //GFA Basic//, il est préférable d'utiliser une position d'affichage en x multiple de 16, afin d'accélérer la vitesse d'exécution.
-La pésition du morceau de carte visible par rapport à la carte virtuelle
-cst contenu dans les variables lîgne carte ec colonne_carte.
+<code freebasic>
-En mettant Tigne carte ot colonne carte à 1, lé côté haut gauche
+OPTION BASE 1
-de la carte est affiche sur Pecran.
+'
-Pour déplacer là carte d’une position vers la droite, il faut incrémenter
+xcarte%=16
-la variable colonne liane de 1 et appeler de nouveau
+ycarte%=5
-@aff carte.
+'
-Fnur_q:'LËFÏ:m':,r la carte d'une position vers le bas, il faur incrementer
+ligne carte%=30
-ligne carte er exécuter Baff carte.
+colonne_carte%=67
-Remarque: la position (1, 1) correspond au premier indice du tableau
+'
-conténant la carte, grice à l’instruction OPTION BASE 1 Sans celle-
+@aff_carte
-ci, le premier indice du tableau a la position (0,0).
-Le morceau de carte visible est affiché à l'écran à la position définie
-par les variables xcarte* et ycarte*. Etant donnd là sccucture interne
-de la mémoire vidéo et la manière dont fonctionnent les Instruetions
-graphiques du GE4 Basic, il est préférable d'utiliser une position
-d'affichage en x multiple de 16, alin d'accélérer la vitesse
-d'exécution.
-OFTION BASE 1
-scartes=16
-vcarté%=5
-ligne cartes=30
-cn]unng_cart&%=ñ?
-éaff carte
 END
-PROCEDURE aff carte i
-LOCAL 1%,c0%
+PROCEDURE aff_carte
-LOCAL 1ignes
+  LOCAL l%,c%
-LOCAL colonne%
+  LOCAL ligne%
-LOCAL nums
+  LOCAL colonne%
-LOCAL posx
+  LOCAL num%
-LOCAL posy®
+  LOCAL posx%
-posyesycartes
+  LOCAL posy%
-ligne¥=ligne cartes
+  '
-FOR 1=1 TO 11
+  posy%=ycarte%
-posx#=xcartes
+  ligne%=ligne_carte%
-colonne*=colonne carte*
+  FOR l%=1 TO 11
-FOR c%=1 TO 11
+    posx%=xcarte%
-numé“carte| (colonne®, ligne#)
+    colonne%=colonne_carte%
-PUT posx%,posy&,elements{(numé)
+    FOR c%=1 TO 11
-INC colonnes
+      num%=carte|(colonne%, ligne%)
-ADD posx%,16
+      PUT posx%,posy%,element${(num%)
-NEXT c&
+      INC colonne%
-INE ligne=
+      ADD posx%,16
-ADD posyé,16
+    NEXT c%
-NEXT 1%
+    INC ligne%
+    ADD posy%,16
+  NEXT l%
 RETURN
-Pour gérer les déplacements, il suffit d’avoir une série de procédures
+</code>
-modifiant les variables de position en fonction de la direction de
-déplacement. Pour des misons de sécurité, ces procédures doivent
+Pour gérer les déplacements, il suffit d’avoir une série de procédures modifiant les variables de position en fonction de la direction de déplacement. Pour des misons de sécurité, ces procédures doivent contrôler que le déplacement ne se fasse pas en dehors des limites de la carte.
-controler que le -l:ié[;];mt‘.m:m né sé fasse pas en dehors des limites de
-la carte.
+<code freebasic>
-ATARI MAGAZINE H BEST OF GFA BASIC
+PROCEDURE aller_haut
-PROCEDURE aller haut
+  IF ligne_carte%<>1
-IF ligne cartes==1
+    DEC ligne_carte%
-DEC 1igne cartes
+    @aff_carte
-Baff carte
+  ENDIF
-ENDIF
 RETURN
-PROCEDURE aller bas
+'
-IF ligne cartese=ligne max®
+PROCEDURE aller_bas
-INC ligne carte%
+  IF ligne_carte%<>ligne_max%
-Baff carte
+    INC ligne_carte%
-ENDLF
+    @aff_carte
+  ENDIF
 RETURN
-PROCEDURE aller gauche
+'
-F colonne cartesss-1
+PROCEDURE aller_gauche
-DEC calonne cartes
+  IF colonne_carte%<>1
-Baff carte
+    DEC colonne_carte%
-ENDIF
+    @aff_carte
+  ENDIF
 RETURN
-PROCEDURE aller droite
+'
-IF colonne carte*=-
+PROCEDURE aller_droite
-INC colonne cartes
+  IF colonne_carte%<>1
-Gaff carte
+    INC colonne_carte%
-ENDT F
+    @aff_carte
+  ENDIF
 RETURN
-Ce système est parfait sur le papier, mais une fois mis en ceuvre, il se
+</code>
-révéle trop lent pour une utilisation pratique, cas de figure fréquent
-en informartique, La solution passe par une amélioration du principe
+Ce système est parfait sur le papier, mais une fois mis en oeuvre, il se révèle trop lent pour une utilisation pratique, cas de figure fréquent en informatique. La solution passe par une amélioration du principe de base.
-de base.
-Un redessin partiel de la carte
+==== Un redessin partiel de la carte ====
-On peut gagner du temps en ne redessinant qu'une partie de la carte.
-Lors d'un déplacement vers la droite, la colonne 1 disparaît de
+On peut gagner du temps en ne redessinant qu'une partie de la carte. Lors d'un déplacement vers la droite, la colonne 1 disparaît de l'écran et les colonnes 2 à 11 sont décalées d'une position vers la gauche, le programme ne dessine vraiment que la nouvelle colonne 11, De la même manière, lors d'un déplacement vers la droite, seule la colonne 1 est nouvelle, Puisqu'une partie de la carte est juste décalée, au lieu de le redessiner, on peut la déplacer en une seule opération graphique. L'une des solutions possible est de lire la portion de carte avec l'instruction ''GET'' et de l’afficher à sa nouvelle position avec ''PUT''.
-l'écran et les colonnes 2 à 11 sont décalées d'une pasition vers la
-gauche, le programme ne dessine vraiment que la nouvelle éolônne
+Cette technique fonctionne, mais présente un inconvénient d'ordre esthétique, L'oeil humain est un outil très perfectionné qui est capable d'analyser et de décomposer la structure d'un mouvement rapide.
-, De la même manière, lors d'un déplacemient vers la dronté,
+C'est souvent un avantage, mais dans notre cas particulier, c’est un inconvénient: si la routine d'affichage travaille en deux étapes, cela produit un effet graphique nuisible visible. Pour éviter cela, il faut que l’affichage s’effectue en une seule fois et le plus rapidement possible.
-seule la colonne 1 est nouvelle, Puisqu'une partie de la carte est justé
-décalée, au licu de le redessiner, on peut la déplacer en une seulc
+La seule manière d'obtenir un affichage rapide est de réaliser les opérations graphiques en mémoire et de les recopier rapidement sur l'écran en une seule opération. Afin d’obtenir un résultat graphique encore meilleur, le programme ''EDITCART'' utilise une variante de cette technique: il dessine la carte dans un écran virtuel, puis change l’adresse de la mémoire écran par l'adresse de cet écran virtuel. Ainsi, on évite de recopier l'image sur l'écran.
-opération graphique. L'une des solutions possible est de lire la portion
-de carte avec l'instruction GET er de l’afficher à sa nouvelle position
+La fonction ''XBIOS(5)'' permet de changer l'adresse de la mémoire écran. Sur un STE cette adresse peut être quelconque, alors que sur un STF elle doit obligatoirement être un multiple de 256. L'adresse initiale de l’écran est multiple de 256. Il faut créer une zone de 32000 octets pour l'écran virtuel. L’instruction ''MALLOC'' permet d'allouer une zone mémoire de n octets. Cette zone mémoire commence obligatoirement à une adresse paire. Pour obtenir une adresse multiple de 256, il faut déclarer avec ''MALLOC'' une zone de 32255 octets et masquer les deux derniers bits de l'adresse Le résultat est une adresse multiple de 256 qui ports sur une zone mémoire de 32000 octets contenus dans la zone mémoire de 32255 octets déclarée par le programme. C'est un peu compliqué mais cela marche bien.
-avec PUT,
-Cette technique fonctionne, mais présente uñ inconvénient d'ordre
+<code freebasic>
-esthétique, L'oeil humain est un outil trés perfectionné qui est capable
+adr_tampon%=MALLDC(32255)
-d'analyser et de décomposer la structure d'un mouvement rapide.
+adr2%=(adr_tampon%+255) AND &HFFFFFF00
-C'est souvent un avantage, mais dans notre cas particuliér, c'ést
+</code>
-un inconvénient: si la routine d'affichage travaille en deux étapes, cela
-produit un effet graphique nuisible visible. Pour éviter cela, il faut
+Les variables //adrl%// et //adr2%// contiennent l'adresse des deux écrans. La variable //adr1%// contient l'adresse initiale de la mémoire écran et //adr2%// contient l'adresse de l’écran virtuel de 32000 octets. L'affichage se fait en bascule. Lorsque l’adresse de la mémoire écran est positionnée sur //adr1%//, l'image de la nouvelle carte est dessinée dans //adr2%// Lorsque l’adresse de la mémoire écran est positionnée sur
-que l’affichage s'effectne en une seule fois et le plus rapidement possible,
+//adr1%//, l'image de la nouvelle carte est dessinée dans //adr1%//.
-La seule manière d'obtenir un affichage rapide est de réaliser les
-opérations graphiques en mémoire et de les recopier rapidement sur
+Lorsque le programme a terminé de dessiner une image en mémoire, il change l'adresse de la mémoire écran grace à l’instruction ''XBIOS(5)''. Attention: la fonction ''XBIOS(5)'' peut être appelée à tous moment par le programme, mais le gestionnaire d’écran ne change l'adresse de la mémoire écran que lorsque l'image courante à été entiérement dessinée, St vous utilisez trop rapidement l'instruction ''XBIOS(5)'', seul le dernier changement de mémoire d'écran sera pris en compte. Pour éviter ce probléme, aprés avoir utilisé ''XBIOS(5)'', il faut attendre que le gestionnaire d'écran ait affiché entièrement l'image écran. Ce test est réalisé avec l'instruction ''VSYNC'' Celle-ci bloque l'exécution du programme tant que le gestionnaire d'écran affiche l’image courante (il y à 50 images affichés par seconde).
-Pécran en une setle opétration. Afin d'obrenir un résultat graphiqué
-encore meilleur, le programme EBITCART utilise une variante de cetté
+<code freebasic>
-technique: il dessine la carte däns un écran virtuel, puis change
+VOID XBIOS(5)
-l’adresse de la mémoire écran par l'adresse de cet écran virtuel. Ainst,
-on évité de recopier l'imagé sur l'écran.
-La fonction XBI0S(5) permet de changer l'adresse de la mémoire
-écran. Sur un STEE cette adresse peut être quelconque, alors que sur
-un STE elle doit obligatoirement être un multiple de 256. L'adresse
-initiale de l’écran est multiple de 256. Il faut créer une zone de 32000
-Dclets pour l'écran virtuel. L'inscruction MALLOC permet d'allouer
-une zonc mémoure de à octéts Cette zone métnoire commence oblipatoirement
-à une adresse paire- Pour obtenir une adresse multiple
-de 256, 1] faut déclarer avec MALLOC une zone de 32255 octets ct
-masquer les deux derniers bits de l'adresse Le résultar est une adresse
-multiple de 256 qui ports sur une zoné mémoire de 32000 octers
-contenus dans la zone mémoite de 32255 octets déclarée par le programme,
-C'est un peu compliqué mais cela marche bien,
-adr tampon#=MALLDC(32255)
-adré#=(adr tampon%+255) AND KHFFFFFFO0
-Les vartables adrl% et adr2% contiennent l'adrésse des deux écrans.
-La varable adr1% contient l'adresse inimiale de la mémoire écran et
-adr?% contienr l'adresse de l’écran virtuel de 32000 octers. L'atfichagé
-se [ait en bascule. Lorsque l’adresse de la mémoire ééran est post
-tionnée sur adrl®, l'image de la nouvelle carte est dessinée dans
-adr?% Lorsque l’adresse de la mémoire écran est positionnée sur
-adrls, l'image de la nouvellé carte est dessinée dans adriér
-Lorsque le programme a terminé de dessiner nne image en mémoire,
-l change Padresse de la mémoire écran grace à l'mnstrucrion
-XB10S(5}. Artention: la fonction XBI0S(5) peur être appélée à rous
-moment par le programme, mais le gestionnaire d'éctan ne change
-Padresse de la mémoire‘écran que lorsque l'image courante à ét éentiérement
-dessinée, St vous urilisez trop rapidement l'instruction
-XBIOS(5}, seul le dernier changement de mémoire d'écran sera pris
-én compré. Pour éviter ce probléme, aprés avoir wrilisé XBI0S(5), il
-faut attendre que le gestionnaire d'écran aic affiché entierement
-l'image écran. Ce test est réalisé avec l'mstruction VEYNC Celle-er
-bloque l'exécution du programme tant que le gestionnaire d'écran atfiche
-l’image courante (il y à 50 images affichés par seconde).
-vOID XBIOS(5)
 VSYNC
-Format de sauvegarde des cartes
+</code>
-Les cartes génerées par EDITCART ont une taille de 30 lignes de 60 colonnes.
-Four changer fa taille, 1l faut modifier les variables nb_colonnes
+==== Format de sauvegarde des cartes ====
-et nb Tignes sans dépasser les limites du tableau carte(
-,75).
+Les cartes générées par ''EDITCART'' ont une taille de 30 lignes de 60 colonnes. Pour changer fa taille, 1l faut modifier les variables //nb_colonnes// et //nb_lignes// sans dépasser les limites du tableau //carte(700,75)//.
-Les cartes d'EDITCART ont le formar suivant: 19 octers conténant la
-chaîne “CARTE JdR ATARI MAG" un octer contenant le nombre de
+Les cartes d'''EDITCART'' ont le format suivant: 19 octets contenant la chaîne "CARTE JdR ATARI MAG" un octet contenant le nombre de colonnes, un octet contenant le nombre de lignes et le codage de la carte (la taille de ce codage est égal à nb_colonnes x nb_lignes octets). La chaîne est un en-tête d'identification. 5i vous tentez de lire un fichier n‘avant pas d'en-tête, le programme affiche un message d'erreur. Le nom d'une carte doit  impérativement avoir une extension ''.CAR'', ne l'oubliez pas au moment de taper de la carte à sauver (c'est l'unique moment où l'éditeur utilise le clavier).
-calonnes, un octet contenant le nombre de lignes et le codage de la
-carte (là taille de cé codage est égal à nb colonnesxnb |îgnes ot
+=== Programme Complet ===
-tets). La chaîne est un en-tête d'identification. 5i vous tentez de lire
-un fichier n‘avant pas d'en-tête, le programme affiche un message
+<code freebasic>
-d'érreur. Le nom d'une carte doit impérativement avoir uné excenson
+' ******************************
-.CAR, ne l'oubliez pas au moment de taper de la carte à sauver
+' *       EDITEUR DE CARTE     *
-(c'est l'unique moment où Péditeur utilise le clavier).
+' *       POUR JEU DE RÔLE     *
-ATAR| MAGAZINE m BEST OFGFA BASIC
+' *        STYLE ULTIMA        *
-| HÉVÉENVÉATAETETETTTENNAETEREETAEE E
+' ******************************
- EDITEUR DE CARTE ñ
+' * (C) 1991 ATARI MAGAZINE    *
-r POUR JEU DE RÔLE =
+' * (C) 1991 PATRICK LECLEREQ  *
-st STYLE ULTIMA *
+' ******************************
-L é d e e e 46 ok e e e e d d d e SE SE e ol e e e R
+'
-“ % - (C) 1991 -ATARI MAGAZINE *
-* (C) 1991 PATRICK LECLEREG #
-RR B b R E RR RR E R RR RR RE EF E
 RESERVE 100000
+'
 OPTION BASE 1
-DIM element$ (200)
+DIM element$(200)
-adr tampon&=MALLOC(32255)
+'
-ad?2%=[adr_tamflun%+255} AND SHFFFFFFOO
+adr_tampon%=MALLOC(32255)
-adr1*=XB105{#)
+adr2%=(adr_tampon%+255) AND &HFFFFFFOO
-nb colonness=60
+adr1%=XBIOS{2)
-nb_lignes*=30
+nb colonnes%=60
+nb_lignes%=30
 DIM carte|(200,75)
-Gmair
+'
+@main
 VOID XBIOS(5,L:adrl%,L:adrl%,-1)
 CLS
 VOID MFREE(adr tampon%)
 END
-PROCEDURE set ecr Tog(adr ecrans)
+'
-VOID X810$(5,L:adr ecrans,L:-1,-1)
+' -----------------------------------
+PROCEDURE set_ecr_log(adr ecran%)
+  VOID XBIOS(5,L:adr_ecran%,L:-1,-1)
 RETURN
-PROCEDURE set ecr phys([adr ecran“)
+'
-VOID XBIOS(5,L:-1,L:adr ecran*,-1)
+PROCEDURE set_ecr_phys([adr ecran%)
+  VOID XBIOS(5,L:-1,L:adr_ecran%,-1)
 RETURN
-— — ===" c=s cs — e ] e e e e e C
+'
-A 045446 GRR A UE UE É ÉÉ R AN RE E E S
+' -----------------------------------
-' # ATTENTE ARRET CLIC SQURIS *
+' ***********************************
-el e e e o e e e e e e e d Sl et e e r ol
+' *    ATTENTE ARRET CLIC SQURIS    *
-PROCEDURE attbclac
+' ***********************************
-i)
+PROCEDURE attOclic
-EXIT IF MOUSEK=0
+  DO
-LOUP
+    EXIT IF MOUSEK=0
+  LOOP
 RETURN
-PROCEDURE Euurîa_fleche
+'
-DEFMOUSE 0
+PROCEDURE souris_fleche
+  DEFMOUSE 0
 RETURN
-PROCEDURE souris abeïlle
+'
-GEFMOQUSE Z
+PROCEDURE souris_abeille
+  DEFMOUSE 2
 RETURN
-| e e e ke o i E o o RE S R ok RR RN
+'
-‘% TEST CLIC SUR ZONE ÉCRAN *
+' ************************************
-A A A A r P e S S o d e m LT
+' *    TEST CLIC SUR ZONE ÉCRAN      *
-FUNCTION tstzone(x*,y%,px5, pyé, txs, tyf)
+' ************************************
-LOCAL results
+FUNCTION tstzone(x%,y%,px%, py%, tx%, ty%)
-result%=l
+  LOCAL result%
-IF xe<pxs —
+  '
-resu]t*=0
+  result%=l
-ENDIF
+  '
-IF x4=px&ttx+-1
+  IF x%<px%
-result#0
+    result%=0
-ENDIF
+  ENDIF
-LF yésepys
+  IF x%>px%+tx%-1
-result#=0
+    result%=0
-ENDIF
+  ENDIF
-IF yve=pysitys-l
+  IF y%<py%
-result=eD
+    result%=0
-ENDIF
+  ENDIF
-RETURN resuLl%
+  IF y%=py%+ty%-l
-ERDFUNE
+    result%=0
-I B o A S ARl e B e o be
+  ENDIF
-' * EFFACEMENT ECRAN
+  RETURN result%
-| NAAAÉERERF REÉSEREE RTEN
+ERDFUNC
-PROCEDURE cls _ ecran(e®)
+'
-DEFFILL c%
+' ************************************
-FBOX 0,0,319,199
+' * EFFACEMENT ECRAN                 *
+' ************************************
+PROCEDURE cls_ecran(c%)
+  DEFFILL c%
+  FBOX 0,0,319,199
 RETURN
-#
+'
-Ah b o i i E É É e i e e e S A RR AT
+' ************************************
-* # AFFICHAGE CADRE GRAPHIQUE w
+' *    AFFICHAGE CADRE GRAPHIQUE     *
-| RR L e R LR S E
+' ************************************
-PROCEDURE cadre[px%, pys,tx%, tyd, f=,bé)
+PROCEDURE cadre(px%,py%,tx%,ty%,f%,b%)
-LOCAL pxé%, pyes
+  LOCAL px2%, py2%
-pxés"pxe+txe=l
+  '
-pyés=pyésttys-1
+  px2%=px%+tx%-1
-DEFFILL f #
+  py2%=py%+ty%-1
-FEOX pxS,0V5, pad%s, pyas
+  DEFFILL f%
-COLOR bé
+  PBOX px%,py%,px2%,py2%
-BOX px%,py%,px2%,pyd%
+  COLOR b%
+  BOX px%,py%,px2%,pyd%
 RETURN
-| ERRRREAA TR RR AN N EEFE
+'
-“ * AFFICHAGE MESSAGE
+' ************************************
-* * DANS ROITE DE CLIC
+' *         AFFICHAGE MESSAGE        *
-ETENESÉ É R
+' *        DANS BOITE DE CLIC        *
-PROCEDURE aff boite(ptxad,% ty,f, pFésy, Déssa m,é)
+' ************************************
-LOCAL pxes, pyes
+PROCEDURE aff_boite(px%,py%,tx%,ty%,f%,b%, m$)
-LOCAL xaff=,yaff4
+  LOCAL px2%, py1%
-pXx24=ox=+Lx==-1
+  LOCAL xaff%,yaff%
-pyeés=pyt+tys-1
+  '
-xaffs=pxt+(tx5-LEN(m$}#8)/2
+  px2%=px%+tx%-1
-yaffa-pyetôt(tyt-7)/2
+  py2%=py%+ty%-1
-ATARI MAGAZIME H BEST-OF GRA BASIC
+  '
-w
+  xaff%=px%+(tx%-LEN(m$}*8)/2
-¥
+  yaff%=py%+6+(ty%-7)/2
-DEFFILL 3%
+  '
-PEOX px%,pye, prés, pyés
+  DEFFILL f%
-COLOR b*
+  PBOX px%,py%, px2%, py2%
-EOX px* pyt, pX24 , pyd=x
+  COLOR b%
-TEXT xa, fvafffä,*mf
+  BOX px% py%, px2% , py2%
+  TEXT xaff%,yaff%,m$
 RETURN
-| IRRFN ENF F
+'
-! * CHARGEMENT DU FICHIER BINAIRE %
+' *************************************
-! + CONTENANT LES ELEMENTS GRAPHIQUES *
+' *   CHARGEMENT DU FICHIER BINAIRE   *
-I ORRÉÉÉÉTARARRE NN RR E E RRARERARA RE
+' * CONTENANT LES ELEMENTS GRAPHIQUES *
-PROCEDURE charge elements({fichierf)
+' *************************************
-LOCAL n%
+PROCEDURE charge_elements({fichier$)
-LOCAL palettet ;
+  LOCAL n%
-palettet=SPACE$(32}
+  LOCAL palette$
-OPEN "1" ,#1,fichierf
+  '
-BGET #1,VARPTK(palette$),32
+  palette$=SPACE$(32)
-VOID XBIOS (6;L:VARPTR(palette$))
+  OPEN "1" ,#1,fichier$
-nb elementsi=INP{#1)
+  BGET #1,VARPTR(palette$),32
-FOR n%=1 TD nb_elements*
+  VOID XBIOS (6;L:VARPTR(palette$))
-element$(n%)=5PACE$ (134)
+  nb_elements%=INP{#1)
-BGET #1,VARPTR(element#(n#}},134
+  FOR n%=1 TO nb_elements%
-MEXT n%
+    element$(n%)=SPACE$(134)
-CLOSE #1
+    BGET #1,VARPTR(element$(n%)),134
+  NEXT n%
+  CLOSE #1
 RETURN
-L EACAAUARERE S R RR E RE RV e e d d d e
+'
-* * INITIALISATION DE LA CARTE *
+'
-| RE d e d e e e R e A E
+' ************************************
-PROCEDURE init carte
+' * INITIALISATION DE LA CARTE       *
-ARRAYFILL carte[(),l
+' ************************************
+PROCEDURE init_carte
+  ARRAYFILL carte|(),l
 RETURN
+'
 D R e b L e R S R o
 ' * AFFICHAGE IMAGE EDITEUR *
@@ Ligne 801: / Ligne 735: @@
 xcartes=6
 vcartes=l=
-Gcharge elements ("ELEMENTS.BIN®)
+  @charge_elements ("ELEMENTS.BIN®)
-@init carte
+  '
-HIDEM
+  @init_carte
-GRAPHMODE 2
+  HIDEM
-@aff ecran
+  GRAPHMODE 2
-@aff carie
+  @aff_ecran
-BMOVE XBIOS(Z2),adr2%,32000
+  @aff_carte
-@souris fleche
+  BMOVE XBIOS(2),adr2%,32000
-SHOWM
+  '
-etats=1
+  @souris_fleche
-@gestion eciteur
+  SHOWM
+  etat%=1
+  @gestion_editeur
 RETURN
-Pour finir
+</code>
-Nous verrons le mois prochain comment uriliser les cartes générées
-par EDITCART pour gérer les déplacéments d'une équipe de personnagés
+==== Pour finir ====
-sur un monde virruel (affichage de l'image de l'equipe sur la
-carte, gestion des rencontres, interdictions où Autorisation de deplacements
+Nous verrons le mois prochain comment utiliser les cartes générées par ''EDITCART'' pour gérer les déplacéments d'une équipe de personnages sur un monde virtuel (affichage de l'image de l'equipe sur la carte, gestion des rencontres, interdictions ou autorisation de deplacements sur certaines cases, etc.) Vous trouverez en téléchargement sur le **3615 ATARI** les listings de l’article, un exemple de carte et une image //Degas// contenant quelques éléments de dessin.
-sur certaines cases, e'n:] Vous trouverez én E:ËlÈ:härg,Emflnl:
-sur le 3615 ATARI les listings de l’article, un exemplé de carte et
-une image Degas contenant quelques éléments de dessin.
 Patrick Leclereq

Nox-Rhea WiKi

Outils pour utilisateurs

Outils du site

Différences

Outils de la page