Discussion :

[Ninored]

Bonjours je rencontre un problème sur l'avancement d'un projet personnel, tout est dans le titre, j'aimerais créer un type de sauvegarde pour des maps en 3D et des données quelconques, j'aimerais aussi optimiser ce fichier en créant mes variables bits a bits (du genre ne pas utiliser une variable trop grande comme le char alors que la donnée peut être contenue que de 1 bit et non 1byte = 8bit ).

Je rencontre une difficulté au faite d'éditer le fichier qui va recueillir tout ça ... j'aimerais vraiment l'éditer à la limite de l'hexadécimal pour que cela soit optimiser.

Quand a la sauvegarde de la map je ne sais pas du tout comment faire car: c'est une map généré aléatoirement, et je ne veux pas de map du type Tiles ( 0 = sol 1= mur .... ).

Merci de vos réponses anticipées.

[Médinoc]

Si tu optimises, attention à bien définir le compromis entre taille occupée et vitesse de sauvegarde/chargement: Plus tu écris en termes plus petits que des entiers système (et pire, en termes plus petits que des bytes), plus ce sera lent (même si tu écris tout en mémoire pour ensuite écrire sur le disque d'un bloc, ce sera plus lent).

Pour ta map, il faudrait déjà savoir comment tu la stockes en mémoire: C'est le premier pas pour savoir ce qu'il y a à enregistrer dans le fichier.

[Ninored]

Le map serra fait avec Perlin noise mais je ne veut pas mettre les données de la map brute dans un fichier ... (pour éviter des modification instantanée) elle serra sauvegardée dans un fichier avec une extension quelconque (je travaille sous linux donc pas besoins de se soucier des extensions). Ma question est n'y a-t-il pas un moyens de faire dans l'entre deux la compresser et la rendre rapidité.
Je vois montre une structure que j'ai pensé pour la sauvegarde de la map:

• Coordonée du Chunk (X;Y)[char] <-- pas plus de 255
  
  • Block ( pour regrouper les données)[utin] <-- pour le designer
    
    • Id block(0 - ...)[uint]
    • Coordonée du block(X;Y)[int] <--- peut être négatif

Peut elle être mieux ??

Pour les données sur le joueur ou autre j'ai compris.

[Médinoc]

Compresser des données basées sur des valeurs aléatoires? Peu de chance d'y gagner grand-chose.

Au pire, si tu veux éviter une modif de ta map dans le fichier par un tiers, tu l'écris en brut et tu ajoutes une signature numérique...

En fait, pour déterminer une compression éventuelle, il faut savoir comment est ta map.
Un truc tout bète comme ceci:

Code X :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
######### ##########
#                  #
#                  #
#                  #
#                  #
#                  #
#                   
#                  #
#                  #
#            #     #
#            #     #
#                  #
#                  #
####################

peut facilement se compresser même en RLE, tandis qu'un truc comme ceci c'est plutôt mort de ce côté-là...
En gros, ça dépend vraiment du format de tes maps.
En fait quand on y pense, tu peux même ajouter un champ dans ton fichier qui dit le type de compression (ou non) utilisé pour une map donnée...

[Ninored]

La map serra basé sur un aléatoire contrôlé par un seed, et pour un temps de chargement moindre je la sauvegarde (effectivement j'ai oublier de signaler que la map est en trois dimensions ^^' ). Mon problème est dans la structure de cette sauvegarde, comment faire en sorte qu'elle soit optimisé, qu'elle prenne le moins de place possible et qu'elle ne soit pas modifiable comme celle que tu m'as présenté.

La signature est un moyen mais la Map est charger dynamiquement en fonction du personnage et peut s'agrandir et la signature va donc changer. Pour un comparatif mes mapes ressemblerons à celle de minacraft.

[Kalith]

J'ai aussi codé un clone de minecraft. Le code est un peu vieux maintenant, j'ai commencé une refonte il y a un moment mais je n'ai malheureusement plus le temps de jouer avec ça... En tout cas il y a des binaires à télécharger sur le site, ceux pour linux fonctionnent toujours, pour Windows ça devrait aller aussi. Le code est bien sûr disponible (il y a un dépôt SVN), il n'est pas excessivement documenté mais plutôt propre donc tu peux y jeter un œil si tu veux.

Pour la sauvegarde des cartes, en gros je m'en était sorti en découpant le monde en régions de 8x8x8 "chunks" (chacun contenant 15x15x15 blocs, donc une région fait 120 blocs de côté). Je sauvegarde ensuite chaque région dans un fichier binaire différent, qui contient un en tête fixe suivi des blocs de la carte compressés en LZMA (avec zlib) pour gagner de la place (chaque bloc est sauvegardé sous la forme {uchar type, uchar sun_light, uchar light}, si possible le même format qu'en RAM pour limiter les conversions).

Je sauvegarde une région seulement quand elle n'est plus visible, donc soit quand le joueur s'en éloigne trop, soit au moment de quitter le jeu. Et bien sûr je fais tout ça dans un thread séparé, pour ne pas bloquer le jeu.

Je m'étais bien amusé à coder tout ça, mais autant il suffit de quelques jours pour faire une démo avec une petite carte qui fonctionne, autant avoir un monde infini, modifiable et sauvegardé, avec la propagation de la lumière et les collision, le tout avec des performances acceptables, ça prend nettement plus de temps. Mais on apprend beaucoup.

Bon courage

Edit : j'ai oublié de préciser... Inutile de sauvegarder la position des chunks/blocs, leur position en mémoire (ou dans le fichier) donne déjà cette information. En gros si tu n'avais qu'une map 2D de 4 blocs à sauvegarder, tu sais que le bloc en haut à gauche est dans blocs[0], celui en haut à droite dans blocs[1], etc. Ça implique qu'il faut vraiment sauvegarder tous les blocs, y compris les blocs vides. Mais tu y gagnes quand même, grâce à la compression.

[Iradrille]

La map serra basé sur un aléatoire contrôlé par un seed, et pour un temps de chargement moindre je la sauvegarde (effectivement j'ai oublier de signaler que la map est en trois dimensions ^^' ). Mon problème est dans la structure de cette sauvegarde, comment faire en sorte qu'elle soit optimisé, qu'elle prenne le moins de place possible et qu'elle ne soit pas modifiable comme celle que tu m'as présenté.

La signature est un moyen mais la Map est charger dynamiquement en fonction du personnage et peut s'agrandir et la signature va donc changer. Pour un comparatif mes mapes ressemblerons à celle de minacraft.

Hello,

le temps de chargement est-il vraiment un problème ?
Je m'explique, tu es dans un monde (la map) à priori infini, ta map est découpée en morceau qui ont tous la même taille.
Chaque morceau contient un nombre déterminé de blocs.
Tu garde en mémoire 27 morceaux : celui ou est le joueur et les 26 autours.

Quant le joueur change de morceau, tu sauvegardes les morceaux qui disparaissent et chargent (ou génère) les morceaux requis pour toujours avoir 27 morceaux aux alentours du joueur.
-> Tu peux faire cette opération en arrière plan (dans un thread à part) si tu peux être sur que le joueur ne verra pas les morceaux à charger tout de suite (donc si tes morceaux sont assez gros et pas transparent, ou si le seuil de vision est plus faible que la taille d'un morceau).
Et même si la sauvegarde / chargement prends plusieurs secondes, tant que tu peux être sur que pendant ce temps le joueur ne peux pas voir les blocs à charger, il n'y à pas de problèmes.

Après plusieurs solutions :
1 - Sauvegarder seulement les données nécessaire à la génération du morceau (seed initial et paramètres de l'algo de Perlin), ainsi que les modifications apportées au bloc.
C'est possible seulement si la génération ne prend pas trop longtemps, et ça te générera des petits fichiers tant que le joueur n'a pas fait trop de modifications sur le morceau.
2 - Dump le morceau, puis y appliquer une compression type zip ou lzw. (Je suppose qu'il y aura très souvent des blocs identiques collés, et donc un fort taux de compression).