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 19:29] – 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 - WIP =====
+===== 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 9: / Ligne 11: @@
 ==== Dessin de la carte ====
-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 ot les autres données graphiques
+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.
 ==== 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.
-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
-SONt CTÉES.
+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.
 Même un non-graphiste peut réaliser une jolie carte à partir de beaux éléments de base.
@@ Ligne 66: / Ligne 50: @@
 ==== Dessin de la carte Ultima ====
-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. Lorsqu’on se déplace sur la carte, le programme est visualisé par une portion de la carte affichée à l’écran.
+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.
-Les ordres de déplacements, l’image de la carte et l’ensemble de ses éléments ne sont qu’un contenu de carte visible.
+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.
 ==== Programmation d’un système de déplacement style Ultima ====
+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
+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?
+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.
-Pour réaliser un système de déplacement similaire à celui d’Ultima, en GFA Basic, il faut tout d’abord définir les éléments graphiques nécessaires. Nous avons déjà vu le codage de la carte peut être stocké dans un tableau unidimensionnel. Il est possible de faire une base de données en chaîne alphabétique, mais il est plus utile de le stocker dans un fichier binaire. Ce fichier regroupe les informations issues de l’image de la carte. Comment afficher rapidement tous ces éléments dans un STF (sur un STE)? Comment stocker les différents éléments pour qu’ils soient facilement lisibles par les déplacements ?
 ==== Définition des éléments graphiques ====
-On suppose que les éléments graphiques ont tous été dessinés par un graphiste avec un logiciel de dessin type Dega Elite ou équivalent. Nous précisons bien que nous parlons de dessins pour écran moyen en 16 couleurs. Pour éditer facilement ces éléments GFA l’image est chargée. ELEMENTS.PI1 est le fichier des éléments graphiques dans un format standard.
+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 structure du fichier est simple. Elle se compose de 32 octets contenant la palette, suivie de l’image de 32000 octets représentant les 200 lignes. Le fichier contient donc 32032 octets. Chaque élément graphique est défini par une portion de l’image de 16 x 16 (x,y) et donné dans un tableau. Le fichier binaire est formé de la façon la plus simple : on extrait tous les éléments, ligne par ligne, fin de ligne, fin de données entraîne l’écriture d’un fichier.
+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
 <code freebasic>
-' *************************
+' ******************************
-' * CHARGEMENT IMAGE
+' * GENÉRATEUR FICHIER BINAIRE *
-' * DEGA ELITE
+' *    ELEMENTS GRAPHIQUES     *
-' *************************
+' ******************************
+RESERVE 100000
+DIM element$(200)
+nb_elements%=0
+palette$=SPACE$(32)
+'
+@load_dzgas("ELEMENTS.PI1")
+@saisie_elements
+@sauve_elements({"ELEMENTS.BIN")
+END
+'
+' ******************************
+' * CHARGEMENT IMAGE           *
+' *    DEGAS ELITE             *
+' ******************************
+'
+' **********************************
 ' * La palette est stockée dans la *
-' * variable globale palette$
+' * variable globale palette$      *
-' *************************
+' **********************************
 PROCEDURE load_degas(nom$)
-  DIM palette$(32)
+  palette$=SPACE$(32)
-  OPEN "I",#1,nom$
+  OPEN "1",#1,nom$
-  BGET #1,varptr(palette$),32
+  SEEK #1,2
-  BGET #1,varptr(elements$),32000
+  BGET #1,VARPTR(palette$),32
-  CLOSE #1
+  VOID XBIOS(6,L:VARPTR(palette$))
+  BGET #1,XBIOS(2),3#000
+  CLOSE #l
 RETURN
+'
-' *************************
+' **********************************
-' * GENERATION FICHIER BINAIRE
+' * GENERATION FICHIER BINAIRE     *
-' * ELEMENTS GRAPHIQUES
+' * ELEMENTS GRAPHIQUES            *
-' *************************
+' **********************************
+PROCEDURE sauve_elements{fichier$)
-PROCEDURE sauve_elements(fichiers)
+  LOCAL i%
-LOCAL nb, i
+  OPEN "o",#1,fichier$
-  DIM e$(1),fichier$
+  BPUT #1,VARPTR(palette$),32
-  OPEN "O",#1,fichiers
+  OUT #1,nb_elements%
-  FOR i=1 TO nb_elements
+  FOR i%=1 TO nb_elements%
-    PUT #1,e$(1)
+    BPUT #1 ,VARPTR(element$(1%)},134
-  NEXT i
+  NEXT i%
   CLOSE #1
 RETURN
+'
-' *************************
+' **********************************
-' * CHARGEMENT DES
+' * CHARGEMENT DES                 *
-' * ELEMENTS GRAPHIQUES
+' * ELEMENTS GRAPHIQUES            *
-' *************************
+' **********************************
+PROCEDURE saisie__elements
-PROCEDURE saisie_elements
+  LOCAL n%
+  LOCAL px%, py%
+  LOCAL px2%,py2%
+  '
+  n%=0
   RESTORE def_elements
-  READ nb_elements
+  DO
-  DIM elements$(nb_elements)
+    READ px%
+    EXIT IF pa%=-1
-  FOR i=1 TO nb_elements
+    READ py%
-    READ px1,py1,px2,py2
+    INC n%
-    elements$(i)=GETS$(px1,py1,px2,py2)
+    px2%=px%+15
-  NEXT i
+    py2%=py%+15
+    GET px%,py%,px2%,py2%,element$(n%)
+  LOOP
+  nb_elements%=n%
 RETURN
+'
-' *************************
+' *********************************
-' * POSITION DES
+' * POSITION DES                  *
-' * ELEMENTS GRAPHIQUES
+' * ÉLEMENTS GRAPHIQUES           *
-' *************************
+' *********************************
 def_elements:
-DATA 1
+DATA 1,1
-DATA 1,1,1,1
+DATA 18,1
-DATA 5,1,5,1
+DATA 35,1
-DATA 8,1,8,1
+DATA 52,1
-DATA 10,1,10,1
+DATA 69,1
-DATA 13,1,13,1
+DATA 86,1
-DATA 15,1,15,1
+DATA 1,18
-DATA 18,1,18,1
+DATA 18,18
-DATA 20,1,20,1
+DATA 35,18
-DATA 25,18,25,18
+DATA 52,18
-DATA 35,18,35,18
+DATA 69,18
-DATA 69,18,69,18
 DATA -1
 </code>
@@ Ligne 150: / Ligne 160: @@
 ==== Programme EDITCART ====
+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.
+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.
-Le programme EDITCART est un éditeur de carte virtuelle écrit entièrement en GFA Basic. Il sauve les cartes dans des fichiers binaires. Ces fichiers peuvent être ensuite réutilisés par d'autres programmes pour effectuer une lecture directe à partir du disque, sauvegarde en mémoire, construction de carte de déplacement sur la carte, sélection d’un élément quelconque de la carte, sélection d’un élément de fonction, l’éditeur a tout de même des limitations si on opère un zoom ou une rotation. L’éditeur ne prend pas en compte les options d’édition.
+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 a besoin d’un fichier d’éléments graphiques pour fonctionner. Exécuter le programme GENELEM avant d’utiliser EDITCART. Il vous suffira de charger les éléments dans ELEMENTS.BIN, et de les modifier, mais vous pourrez le modifier dans le code source d’EDITCART ou ajouter des fonctions permettant de charger n’importe quel fichier d’éléments graphiques.
-==== La simplicité n’est pas de ce monde ====
+==== La simplicité n'est pas de ce monde ====
-Initialement, cet éditeur a été conçu pour être simple à utiliser et à programmer, en GFA Basic. Les cartes sont organisées sous forme de chaînes simples. Il est possible d’utiliser une base de données en mémoire pour chaque carte, ou alors de relier une base de données au format binaire, ou EDITCART est utilisé en complément de la gestion des images graphiques complexes pour des techniques de programmation avancées.
+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.
 ==== Un système d’affichage simple ====
-La première méthode qui vient à l’esprit est de réafficher cette portion visible ligne par ligne. Dans l’exemple suivant, les variables ligne_carte et colonne_carte contiennent les coordonnées du coin haut gauche de la carte visible. Le tableau ELEMENTS() contient les éléments graphiques correspondant aux données de la carte.
+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.
-La position du coin de la carte visible par rapport à la carte virtuelle est contenue dans les variables ligne_carte et colonne_carte.
+La position du morceau de carte visible par rapport à la carte virtuelle cst contenu dans les variables //ligne_carte// et //colonne_carte//.
-En mettant ligne_carte et colonne_carte à 1, le côté haut gauche de la carte est affiché sur l’écran.
+En mettant //ligne_carte// et //colonne_carte// à 1, le côté haut gauche de la carte est affiche sur l'ecran.
-Pour déplacer la carte d’une position vers la droite, il faut incrémenter la variable colonne_ligne de 1 et appeler de nouveau eff_carte.
-Pour déplacer la carte d’une position vers le bas, il faut incrémenter ligne_carte et exécuter eff_carte.
+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//.
-Remarque : la position (1,1) correspond au premier indice du tableau contenant la carte, grâce à l’instruction OPTION BASE 1. Sans cette option, le tableau débute à la position (0,0).
-Le morceau de carte visible est affiché à l’écran à la position définie par les variables xcarte$ et ycarte$. Étant donné la 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 des coordonnées d’affichage en x multiple de 16, afin d’accélérer la vitesse d’exécution.
+Pour déplacer la carte d'une position vers le bas, il faut incrémenter //ligne_carte// et exécuter //aff_carte//.
+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).
+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.
 <code freebasic>
@@ Ligne 174: / Ligne 190: @@
 '
 xcarte%=16
-ycarte%=50
+ycarte%=5
-ligne_carte%=1
+'
+ligne carte%=30
 colonne_carte%=67
 '
@@ Ligne 182: / Ligne 199: @@
 PROCEDURE aff_carte
-  LOCAL i,ligne%
+  LOCAL l%,c%
-  LOCAL j,col%
+  LOCAL ligne%
+  LOCAL colonne%
+  LOCAL num%
   LOCAL posx%
   LOCAL posy%
-  LOCAL pos%
   '
-  FOR i=1 TO 11
+  posy%=ycarte%
-    ligne%=ligne_carte%
+  ligne%=ligne_carte%
+  FOR l%=1 TO 11
     posx%=xcarte%
-    FOR j=1 TO 11
+    colonne%=colonne_carte%
-      col%=colonne_carte%
+    FOR c%=1 TO 11
-      pos=carte1(colonne_ligne)
+      num%=carte|(colonne%, ligne%)
-      PUT posx%,posy%,elements(pos)
+      PUT posx%,posy%,element${(num%)
-      INC col%
+      INC colonne%
       ADD posx%,16
-    NEXT j
+    NEXT c%
     INC ligne%
     ADD posy%,16
-  NEXT i
+  NEXT l%
 RETURN
 </code>
-SNIP-SNIP
+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.
+<code freebasic>
-Même un non-graphiste peut réaliser une jolie carte à partir de beaux
+PROCEDURE aller_haut
-éléments de hase.
+  IF ligne_carte%<>1
-==== Dessin de la carte Ultima ====
+    DEC ligne_carte%
+    @aff_carte
-La portion de carte affichée par les jeux Ultima à une dimension de
+  ENDIF
-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
-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é
-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.
-Comment est-ce que les éléments graphiques sont stockes dans
-le tableau alphanumérique? Comment afficher rapidement là carte
-aussi bien sur un STF que sur un STE? Comment stocker les différéntes
-données sur disque? Comment gérer les déplacements de
-l'équipé sur la carte?
-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
-à la créition d'une carte et la seconde traite de son utilsation
-pour gérer les déplacements de l'équipe,
-Définition des éléments graphiques
-On suppese que les éléments graphiques de base ont êté dessinés par
-un graphiste avec un logiciel de dessin type Degas Elite où equivalent.
-Nos précieux cléments sont donc stockes sur disque dans une
-image au format Degas, Le programme GENELEM,GFA lie l'image Degas
-ELEMENTS.P11 et stocke les éléments graphiques dans un fichier
-binaire ELEMENTS . BIN réucilisable par un autre programme.
-La structure du fichier binaire est la suivante: 32 ocrets contenant la
-palette de couleur des éléments graphiques, un oot unique conténant
-le nombre d'élements du Hehier et le codage des éléments, chacun
-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
-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")
-END
-e e 44 E RE W W E R W R R
-* CHARGEMENT-IMAGE *
-= DEGAS ELITE 8
-E T T R P e e T o E E S
-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
-PROCEDURE !oad degas(nom$)
-palettef=SPACE4(32)
-OPEN "T",#1,nom$
-SEEK #1,2 .
-BGET #1 VARPTR(palette$}),37
-VOID XE10S(6,L-VARPTR(palette*))
-BGET #1,XB105{2},3#000
-CLOSE #l
-RETURR
-B o e E T e b É el RE
-* 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
+PROCEDURE aller_bas
-i CHARGEMENT DES %
+  IF ligne_carte%<>ligne_max%
-* ELEMENTS GRAPHIQUES *
+    INC ligne_carte%
-C e RE e dc d PE E E e E A R E R RS
+    @aff_carte
-PROCEDURE saisi E__El ements
+  ENDIF
-LOCAL ns
-LOCAL px%, pyi
-LOCAL px2%,py2%
-nE=0
-RESTORE def elements
-g
-READ px%
-EXIT IF pai==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
+PROCEDURE aller_gauche
-! * ÉLEMENTS GRAPHIQUES *
+  IF colonne_carte%<>1
-| ETEN eE ol e o R E
+    DEC colonne_carte%
-def elements:
+    @aff_carte
-DATA 1,1
+  ENDIF
-DATA 18,1
-DATA 35,1
-DATA 52,1
-DATA 69,1
-DATA 66,1l
-DATA 1,18
-DATA 18,18
-DATA 35,18
-DATA 52,18
-DATA 69,18
-DATA -1
-Programme EDITCART
-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,
-pouvant être relus et exploités par d'autrés programmes.
-Ses fontions 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
-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 à besoïn d'un fichier d’éléments graphiques pour
-foncrionner. Exéeutéz le programme GENELEM avant d'utiliser EDITCART.
-Le nom du fichier d'élements graphiques est ELEMENTS.BIN
-par défaur, mais vous pourrez le modifier dans le code source
-d'EDITCART, ou ajouter une fonction permettant de charger n'imparte
-quel fichier d'éléments graphiques.
-La simplicité n'est pas de ce monde
-Initialement, cet éditeur a Été conçu pour être simple à utiliser et à
--:-:-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
-que tous les ST ne soient pas dotés de blitter). Les routinés
-d'affichage de EDITCART utilisent donc des techniques de programmation
-un peu complexes à comprendre pour un programmeur
-debutant.
-Un système d’affichage simple
-La première méthode qui vient à l'esprit est de réafficher entiérement
-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
-graphiques de base dans le tableau ELEMENTS(). La procedure
-Gaff carte dessine la carté sur l'écran.
-La pésition du morceau de carte visible par rapport à la carte virtuelle
-cst contenu dans les variables lîgne carte ec colonne_carte.
-En mettant Tigne carte ot colonne carte à 1, lé côté haut gauche
-de la carte est affiche sur Pecran.
-Pour déplacer là carte d’une position vers la droite, il faut incrémenter
-la variable colonne liane de 1 et appeler de nouveau
-@aff carte.
-Fnur_q:'LËFÏ:m':,r la carte d'une position vers le bas, il faur incrementer
-ligne carte er exécuter Baff carte.
-Remarque: la position (1, 1) correspond au premier indice du tableau
-conténant la carte, grice à l’instruction OPTION BASE 1 Sans celle-
-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%
-LOCAL 1ignes
-LOCAL colonne%
-LOCAL nums
-LOCAL posx
-LOCAL posy®
-posyesycartes
-ligne¥=ligne cartes
-FOR 1=1 TO 11
-posx#=xcartes
-colonne*=colonne carte*
-FOR c%=1 TO 11
-numé“carte| (colonne®, ligne#)
-PUT posx%,posy&,elements{(numé)
-INC colonnes
-ADD posx%,16
-NEXT c&
-INE ligne=
-ADD posyé,16
-NEXT 1%
 RETURN
-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
+PROCEDURE aller_droite
-déplacement. Pour des misons de sécurité, ces procédures doivent
+  IF colonne_carte%<>1
-controler que le -l:ié[;];mt‘.m:m né sé fasse pas en dehors des limites de
+    INC colonne_carte%
-la carte.
+    @aff_carte
-ATARI MAGAZINE H BEST OF GFA BASIC
+  ENDIF
-PROCEDURE aller haut
-IF ligne cartes==1
-DEC 1igne cartes
-Baff carte
-ENDIF
 RETURN
-PROCEDURE aller bas
+</code>
-IF ligne cartese=ligne max®
-INC ligne carte%
+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.
-Baff carte
-ENDLF
+==== Un redessin partiel de la carte ====
-RETURN
-PROCEDURE aller gauche
+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''.
-F colonne cartesss-1
-DEC calonne cartes
+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.
-Baff carte
+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.
-ENDIF
-RETURN
+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.
-PROCEDURE aller droite
-IF colonne carte*=-
+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.
-INC colonne cartes
-Gaff carte
+<code freebasic>
-ENDT F
+adr_tampon%=MALLDC(32255)
-RETURN
+adr2%=(adr_tampon%+255) AND &HFFFFFF00
-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
+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
-de base.
+//adr1%//, l'image de la nouvelle carte est dessinée dans //adr1%//.
-Un redessin partiel de la carte
-On peut gagner du temps en ne redessinant qu'une partie de la carte.
+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).
-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 pasition vers la
+<code freebasic>
-gauche, le programme ne dessine vraiment que la nouvelle éolônne
+VOID XBIOS(5)
-, De la même manière, lors d'un déplacemient vers la dronté,
-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
-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
-avec PUT,
-Cette technique fonctionne, mais présente uñ 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.
-C'est souvent un avantage, mais dans notre cas particuliér, c'ést
-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'effectne en une seule fois et le plus rapidement possible,
-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
-Pécran en une setle opétration. Afin d'obrenir un résultat graphiqué
-encore meilleur, le programme EBITCART utilise une variante de cetté
-technique: il dessine la carte däns un écran virtuel, puis change
-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 936: / 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