Posté le 18/08/2018 23:38
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 130 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
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.
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.
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.
Citer : Posté le 18/08/2018 23:48 | #
ok, merci
Citer : Posté le 19/08/2018 08:45 | #
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.
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.
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 ^^'
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
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.
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.