Format des cartes Landes Eternelles (.elm)

Le format se compose des sections suivantes (dans l’ordre):

Le map Header

longueur totale : 124 octets

  • char file_sig [4] : 4 caractères contenant forcement ‘elmf’ sinon la carte est invalide
  • int tile_map_x_len : un entier signé contenant le nombre de cases sur l’axe X
  • int tile_map_y_len : un entier signé contenant le nombre de cases sur l’axe Y
  • int tile_map_offset : un entier signé contenant l’offset du début du tableau des cases
  • int height_map_offset : un entier signé contenant l’offset du début du tableau des hauteurs de marches
  • int obj_3d_struct_len : un entier signé contenant la longueur de la structure contenant un objet 3D en octet
  • int obj_3d_no : un entier signé contenant le nombre d’objets 3d de la carte
  • int obj_3d_offset : un entier signé contenant l’offset du début du tableau des objets 3D
  • int obj_2d_struct_len : un entier signé contenant la longueur de la structure contenant un objet 2D en octet
  • int obj_2d_no : un entier signé contenant le nombre d’objets 2d de la carte
  • int obj_2d_offset : un entier signé contenant l’offset du début du tableau des objets 2D
  • int lights_struct_len : un entier signé contenant la longueur de la structure contenant un lumière en octet
  • int lights_no : un entier signé contenant le nombre d’objets 2d de la carte
  • int lights_offset : un entier signé contenant l’offset du début du tableau des objets 2D
  • char dungeon : 01 indique un donjon (pas de lumière du jour/ambiante, pas de réflexion des nuages sur l’eau), 00 une carte extérieure (soumis à la lumière du jour et de la nuit, réflexion des nuages sur l’eau)
  • char res_2,
  • char res_3,
  • char res_4  : inutilisé, nous pensons que c’est réservé pour préserver l’alignement a 4 octets (int)

Note : les bits res_2, res_3 et res_4 seront utilisé dans une prochaine révision des elmaptools pour stocker les initiales (res 2 & 3) et le numéro de version de la carte (res_4)

  • float ambient_r,
  • float ambient_g,
  • float ambient_b : certainement la couleur de la lumière ambiante de la carte
  • int particles_struct_len : un entier signé contenant la longueur de la structure contenant un effet de particule en octet
  • int particles_no : un entier signé contenant le nombre d’effet de particule de la carte
  • int particles_offset : un entier signé contenant l’offset du début du tableau des effet de particule
  • int reserved_8,
  • int reserved_9,
  • int reserved_10,
  • int reserved_11,
  • int reserved_12,
  • int reserved_13,
  • int reserved_14,
  • int reserved_15,
  • int reserved_16,
  • int reserved_17 : 10 entiers réservé pour l’avenir soit 40 octets

Un tableau des cases

  • Taille char [x*y]

chaque case est un octet non signé dont la valeur est l’indice dans le tableau des textures de sol le numero indique aussi le fichier texture a prendre (tileX.bmp)

Un tableau des hauteurs de marche

Les tiles font six cases de larges et c’est pour cette raison que la carte des hauteurs (noté height_map dans le source) correspond à x*6 * y*6 et que la carte des tiles fait x*y.
Cela doit correspondre à une hauteur mais la valeur est un char (donc certainement multipliée par un float dans le jeu.
Je pense que la valeur char est importante car elle permet aussi d’avoir un pathfinder plus rapide que si on travaillait sur des floats.

  • Taille char [x*y*6*6]
  • La hauteur est comprise entre -2 et +4 m par pas de 0.2m
  • La hauteur de -2.2m signifie non marchable (valeur 0x00)
  • Il y a 6.2 *0.2 positions soit 31 états différents
  • En valeur char 0x00 veut dire non marchable, 0x01 la plus basse hauteur et 0x1f soit 31 la plus haute
  • 0x0B la valeur standard (soit 11)

Les objets 3d

Taille actuelle : 144 octets

  • char file_name [80] : Le nom du fichier correspondant depuis la racine du client, séparateur de dossier : “/”, finit forcement par “.e3d”
  • float x_pos,
  • float y_pos,
  • float z_pos : Position sur la carte selon les 3 axes
  • float x_rot,
  • float y_rot,
  • float z_rot : rotation sur la carte selon les 3 axes
  • char self_lit : 01 objet plus lumineux. C’est pratique pour visualiser l’intensité lumineuse mais non actif en mode jour. Seulement à l’aube, la nuite et le soir.
  • char blended : 01 met l’objet en évidence avec les décors. C’est assez pratique pour des élément comme le cristal. associé à la couleur ci-dessous.
  • char reserved2 [2] : en quelque sorte pour préserver l’alignement a 4 octets je suppose il y a apres 2octets “vides”
  • float r,g,b : couleur du mode Blended ou lift
  • char reserved [24] : réservé pour utilisation future

Remarque : Si l’objet a été effacé alors la valeur de la variable blended = 20. Ceci afin de préserver l’ordre des objets dont la position dans le tableau est utilisé comme identifiant notamment dans les fichiers DEF sur le serveur.

Les objets 2d

taille actuelle : 128 octets

  • char file_name [80] : le nom du fichier correspondant depuis la racine du client, séparateur de dossier : “/”, finit forcement par “.2d0”
  • float x_pos,
  • float y_pos,
  • float z_pos : position sur la carte selon les 3 axes
  • float x_rot,
  • float y_rot,
  • float z_rot : rotation sur la carte selon les 3 axes
  • char reserved\[24\] : réservé pour utilisation future

les lumières

Taille actuelle 40 octets

  • float pos_x,
  • float pos_y,
  • float pos_z : Position sur la carte selon les 3 axes
  • float r,
  • float g,
  • float b : Couleur de la lumière
  • char reserved [15] : Réservé pour utilisation future, en réalité 16 pour l’alignement a 4 octets (d’ou la taille 40)

Les particules

Taille actuelle : 106 octets

Note : Chaque type de “particule” est stockée dans un fichier à part de la carte. L’éditeur de carte permet de créer et modifier ces fichiers.

  • char file_name [80] : Le nom du fichier correspondant depuis la racine du client, séparateur de dossier : “/”, finit forcement par “.part”
  • float x_pos,
  • float y_pos,
  • float z_pos : Position sur la carte selon les 3 axes
  • char reserved [10] : Réservé pour utilisation future, en réalité 12 pour l’alignement a 4 octets (d’ou la taille 104)

Informations diverses

De façon fort empirique, une case (1/6 sur 1/6 de tile soit 0.5m) correspondrait +/- 0.5 en float sur l’axe des x, y ou z, ce qui serait assez logique vu la façon que le concepteur a eu de faire tout à l’économie en ressource cpu & ram.

Il reste a créer des maps de façon sans l’éditeur pour vérifier.

La position 0 en flottant de l’axe Z serait a l’altitude 0 soit le byte de valeur 11 et donc chaque déplacement de +/- 1char correspond a +/- 0.2 sur l’axe Z.

Distance :

  • 0.5 m correspond a une case (1/6 de tile)
  • 0.5 en flottant correspond a une case donc 1 en flottant correspond a 1m en visuel

Les angles sont en degrés et orienté dans le sens anti-horaire (Ou trigonométrique).

Attention en C les char sont des multioctet ici ce sont plutot des bytes (forcement des char de 1 octets).

Tous les nombres sont en little endian (Le format standard des ordinateurs Intel & Amd).

Note :

Documentation source : Projet ElmapTools d’Etory & XlurP