Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Autres questions


Index du Forum » Autres questions » Windmill : Enregistrement propre des données
Ninestars Hors ligne Membre Points: 2413 Défis: 22 Message

Windmill : Enregistrement propre des données

Posté le 18/08/2018 23:38

Bonjour,
actuellement j'enregistre toutes les données (textures, objets, map) dans map.h que j'ai inclu dans main.c
Seulement j'aurai besoin d'acceder à ces données depuis un autre fichier que main.c et inclure à nouveau map.h crée forcement des doublons ce qui fait planter la compilation.
Je pas mal de variables, il n'est pas question de tout passer en argument.

Comment pourrais-je faire ?
Ou alors comment stocker autrement les données ? S'il y a quelque chose de mieux je suis preneur


Dark storm Hors ligne Labélisateur Points: 11542 Défis: 176 Message

Citer : Posté le 18/08/2018 23:40 | #


Humm, le mieux c'est d'utiliser des extern
En gros tu définis les symboles dans un fichier source, et là où tu en as besoin tu les déclare en extern. C'est ce qui me parait le plus propre.

Par contre, vu que c'est global, t'as intérêt à ce que ce soit du static const pour pas bouffer de la ram outre-mesure.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Ninestars Hors ligne Membre Points: 2413 Défis: 22 Message

Citer : Posté le 18/08/2018 23:43 | #


Ok, mais c'est pas une "mauvaise" manière ça justement ? :/ (Lephé va sauter au plafond)

Toutes les variables de map.h auquelles j'ai besoin d'acceder sont "normales", sans const, ni static, ni...
D'autres variables sont en const.
Dark storm Hors ligne Labélisateur Points: 11542 Défis: 176 Message

Citer : Posté le 18/08/2018 23:46 | #


Ben si t'en as besoin de partout, faut voir ce qui est le plus adapté.

Ceci dit, le coup du extern, nan c'est même plutôt propre, c'est ce qu'utilise gint par exemple (sauf que dans gint, le code objet est directement compilé dans un .o par fxconv, plutôt que de faire des arrays dégueux dans un .c.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Ninestars Hors ligne Membre Points: 2413 Défis: 22 Message

Citer : Posté le 18/08/2018 23:48 | #


ok, merci
Lephenixnoir Hors ligne Administrateur Points: 21025 Défis: 143 Message

Citer : Posté le 19/08/2018 08:45 | #


Ninestars a écrit :
Ok, mais c'est pas une "mauvaise" manière ça justement ? :/ (Lephé va sauter au plafond)

Non, c'est Dark Storm qui a raison. Sauf pour le static. Tu ne peux pas faire de déclarations externes pour des variables statiques (globales), c'est le principe.

Mettre des données dans un header, ça c'est chô hyper moche.

Dark storm a écrit :
Ceci dit, le coup du extern, nan c'est même plutôt propre, c'est ce qu'utilise gint par exemple (sauf que dans gint, le code objet est directement compilé dans un .o par fxconv, plutôt que de faire des arrays dégueux dans un .c.

Voilà, il a tout dit : le mieux serait d'avoir des fichiers au format binaire, et ensuite de générer automatiquement les fichiers objets à partir de ça. Les tableaux de données dans le code c'est quand même très moyen.
Ninestars Hors ligne Membre Points: 2413 Défis: 22 Message

Citer : Posté le 19/08/2018 10:35 | #


D'accord.
Comment générer un fichier au format binaire alors ? Et quel est son avantage sur un fichier écrit en C (qui fini en binaire à la compilation donc je comprends pas trop )
Parce que mes données, j'ai besoin qu'elles soient lisibles et surtout écritent par un humain. Je vais pas demander à l'utilisateur de Windmill d'enregistrer la map en binaire ^^'
Lephenixnoir Hors ligne Administrateur Points: 21025 Défis: 143 Message

Citer : Posté le 19/08/2018 10:59 | #


Pour l'utilisateur du SDK, tu n'as pas le choix... tu devras rester sur les tableaux.

Voici la procédure, quand on compile avec gint par exemple :

1. Sur la ligne de commande, on compile les .c en .o avec gcc
2. Sur la ligne de commande, on compile les .bmp en .o avec fxconv (objcopy)
3. On linke tout avec ld

Et quel est son avantage sur un fichier écrit en C (qui fini en binaire à la compilation donc je comprends pas trop )

D'abord, c'est plus légitime : tu pars d'un chunk de données et tu en fais une section .data. Ce sont des données, pas du code : il n'y a pas de raison de faire du code avec. Tu pourrais avoir des langages de haut niveau où tu ne peux pas définir un chunk de mémoire comme tu le fais avec un tableau de char. Ou alors tu ne peux pas le mettre explicitement dans une section .data. Bref, écrire un programme pour avoir des données, c'est bizarre.

Pus concrètement, la conversion est automatique en ligne de commande ou dans ton Makefile. On peut aussi générer automatiquement un fichier C, je te l'accorde, mais quand on a le choix opter pour le tableau de char est juste stupide.

Parce que mes données, j'ai besoin qu'elles soient lisibles et surtout écritent par un humain. Je vais pas demander à l'utilisateur de Windmill d'enregistrer la map en binaire ^^'

Tu trouves vraiment que c'est pratique d'éditer des maps en hexa ? Quand j'utilise fxconv, j'édite mes images et mes polices avec Gimp ; j'éditerai mes maps avec Tiled ; j'éditerai mes dialogues et mes stats d'items avec un éditeur de texte. Le jour où ton format de map interne change tes utilisateurs devront refaire toutes leurs maps. Moi je n'aurai qu'à mettre à jour fxconv.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2021 | Il y a 41 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd