Posté le 15/07/2017 13:54
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 132 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 14/03/2021 20:41 | #
Ah problème résolue, je n'avais pas vu qu il fallait être dans le fichier complet avant de lancer build-fx, merci beaucoup!!
Citer : Posté le 14/03/2021 21:03 | #
Ouf ! Merci de ta patience. J'espère que tu t'amuseras bien avec les add-ins !
Citer : Posté le 14/03/2021 21:13 | #
Gravity duck sur graph 35 +e2 arrive !!!!( Et deso d'avoir poste mon commentaire sur le mauvais topic)
Citer : Posté le 14/03/2021 21:16 | #
... ce n'est pas vraiment la direction pour faire un portage de Gravity Duck, mais fais ce qui te semble possible.
Pour info il y a un topic qui liste les portages d'add-ins vers la Graph 35+E II, je te conseille d'y faire un tour.
Citer : Posté le 05/04/2021 21:03 | #
Me revoilà sur cette page hahaaa !
J'ai un message d'erreur pour crée un nouveau projet :
fxsdk new coco
Citer : Posté le 05/04/2021 21:07 | #
Il faut que tu identifies ton shell. Je ne sais pas ce que tu utilises mais ça ne doit pas être bash (et c'est le 2/3ème bug à ce sujet).
Note que la procédure est un poil différente si tu utilises CMake, les dossiers sont organisés un peu différemment ; mais dans tous les cas fxsdk build-{fx,cg} te compile l'add-in. Les détails de tutoriel sur le système de compilation sont juste moins pertinents.
Lis aussi ce post quand tu arriveras à la conversion des assets.
Citer : Posté le 09/04/2021 16:09 | #
Donc j'ai eu une idée de projet (secret pour le forum jusque à que ce soit fini) et j'ai besoin de lire des fichiers pour cela. Je regarde donc les headers de la lib, et je trouve LE .h a inclure parfait :
Mais, je regarde le contenu du fichier, et je vois un commentaire qui m'a intrigué
//---
// gint:bfile - BFile interface
//
// The system's file system is a nightmare and the risk of corrupting it
// or the flash by driving it manually is too great to risk. This module
// interfaces with the BFile syscalls for file management.
//---
Donc utiliser cette partie de la lib pourrait causer des problemes à la memoire flash? Et si c'est le cas, je me mets a risque si c'est juste pour lire un fichier?
Citer : Posté le 09/04/2021 16:14 | #
"Le système de fichiers est un cauchemar et le risque de le corrompre en le manipulant manuellement est trop risqué. Ces interfaces utilisent les syscalls Bfile pour la gestion des fichiers."
Traduction : c'est safe. Tout ce que ce commentaire dit, c'est que ce n'est pas implémenté directement dans gint, c'est l'une des seules parties où gint fait appel au système. Mais ce sont des mécanismes internes. Penses juste à utiliser gint_switch() comme le dit le commentaire d'en-dessous, j'avais oublié ce détail.
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 09/04/2021 16:15 | #
Contrôler manuellement la Flash serait un risque... par conséquent, gint ne le fait pas, et utilise à la place BFile (l'interface de l'OS). Tu ne risques rien, fais simplement attention à bien appeler les fonction BFile hors de gint (à savoir dans un gint_switch(), vois <gint/gint.h> pour les détails) et tout ira bien.
Citer : Posté le 09/04/2021 16:44 | #
Aussi, le format de lecture c'est bien
Citer : Posté le 09/04/2021 16:50 | #
Nope, c'est \\fls0\FICHIER.BIN et c'est encodé en FONTCHARACTER (extension 16-bit de Shift-JIS) et y'a qu'un niveau de sous-dossiers. https://bible.planet-casio.com/common/casio/sdk_manuals/Libraries.pdf autour de Bfile_*.
Citer : Posté le 01/05/2021 18:18 | #
J'ai inclue gint/defs/utils pour avoir les min max, mais j'ai une erreur à la compilation : il semble qu'il faille définir __auto_type
Que faut-il faire ?
Citer : Posté le 01/05/2021 18:31 | #
C'est parce que tu fais du C++, et en C++ on peut utiliser le mot-clé auto pour demander au compilateur de deviner le type d'une variable à partir de la valeur avec laquelle on l'initialise. En C, auto veut dire autre chose, et GCC a introduit un mot-clé __auto_type comme extension pour obtenir ce comportement. Bien sûr en C++ l'extension ne sert à rien et n'est donc pas activée.
Bref, en gros il faut écrire auto à la place en C++. J'ai poussé un commit sur dev qui fait exactement ça, dis-moi si ça se passe mieux pour toi (j'ai fait un test mais on sait jamais).
Citer : Posté le 01/05/2021 18:45 | #
OK, merci pour l'explication.
Oui c'est tout bon, ça fonctionne désormais, j'ai toujours d'autres erreurs de compilation mais c'est autre chose
Merci
Ajouté le 01/05/2021 à 19:06 :
Bon tout compte fait, j'ai encore des erreurs, surtout une que je ne comprends pas
main.cpp:(.text.startup+0xc0): undefined reference to `___dso_handle'
main.cpp:(.text.startup+0xc4): undefined reference to `___cxa_atexit'
Windmill: hidden symbol `___dso_handle' isn't defined
Dans main.cpp j'ai 3 variables globales
Windmill windmill;
Scene_Map scene_map;
PS : je cherche avant sur internet avant de t'embêter avec mes questions, mais je trouve pas toujours
Citer : Posté le 01/05/2021 19:10 | #
Argh, le compilateur utilise atexit() (plus spécifiquement _cxa_atexit()) pour exécuter les destructeurs. Le dso_handle est encore plus spécifique et je crois qu'il faut vraiment qu'on compile libstdc++ avec le compilateur si on veut avoir une chance de faire du C++ sérieusement.
Citer : Posté le 01/05/2021 19:35 | #
Arf...
Pourtant, les class fonctionnaient bien jusque là :
Si je fais ça dans main.cpp ça compile nickel
{
public:
int croquette;
Chien();
void manger(int cb);
};
Chien::Chien()
{
croquette = 10;
}
void Chien::manger(int cb)
{
croquette -= cb;
}
Chien pipounie;
blabla
Citer : Posté le 01/05/2021 20:21 | #
C'est parce qu'il n'y a pas de destructeur.
Si tu as encore le dossier dans lequel tu as compilé GCC, je peux faire des essais pour compiler libstdc++. Honnêtement ce serait un niveau de vie complètement différent, avec la STL et tout. Il faut quand même que gint fournisse atexit() et d'autres trucs mais ça c'est jouable.
Citer : Posté le 02/05/2021 10:14 | #
Hmmm en effet, d'ailleurs rien à y faire, j'ai une erreur de compilation sur le ~ quand j'ajoute Chien::~Chien, je saisi pas pourquoi il me "error stray". Peu importe de toute façon
Oui j'ai toujours ce dossier, je suis grave preneur si tu arrives à compiler la stdlibc++. Sans vouloir imposer une quelconque pression, je ne pourrai pas avancer de toute façon sans. Tout mon code est pensé pour le C++
Bref je mes le projet en attente, je suis dispo si tu tester des trucs
Citer : Posté le 02/05/2021 10:25 | #
Hmmm en effet, d'ailleurs rien à y faire, j'ai une erreur de compilation sur le ~ quand j'ajoute Chien::~Chien, je saisi pas pourquoi il me "error stray". Peu importe de toute façon
Oh ça c'est un problème extrêmement superficiel: « stray xxx in program » c'est quand g++ trouve un caractère inconnu dans le code. Tu as dû taper un caractère exotique avec Alt Gr ou une autre fausse manip' du même style. Si ton éditeur de texte ne te montre pas le caractère problématique, tu peux supprimer et réécrire une ligne entière pour t'en défaire. Vérifie que tu utilises bien le tilde ASCII (~).
Aïe, je suis maintenant bloquant pour Windmill, ce qui est très pressant ha ha.
Citer : Posté le 04/05/2021 18:53 | #
Je viens (enfin) de mettre à jour le tutoriel pour le système de compilation CMake. C'est un truc de fou parce que non seulement il faut modifier le texte mais en plus il faut modifier tous les commits du dépôt pour que chaque référence au dépôt dans le corps du tutoriel pointe vers un nouveau commit identique sauf pour le système de build ! x)
Pour les curieux, j'ai simplement créé une nouvelle branche sur le premier commit, modifié le premier commit avec un nouveau projet vide, et ensuite cherry-pick tous les commits un par un et résolu les conflits au fur et à mesure. Le truc a été rendu un peu plus compliqué par le fait que j'avais déjà commencé à éditer le texte, et donc j'avais des modifs pour le 4ème ou le 5ème commit dans l'espace de travail quand j'ai commencé...
J'ai aussi fait toutes les mises à jour récentes liées au fxSDK et j'ai mettre trouvé une fonctionnalité que j'avais oublié de porter durant la mise à jour où j'ai créé fxconv-metadata.txt. Visiblement ça n'a dérangé personne
J'ai laissé une branche "makefile" sur le dépôt pour ceux qui voudraient potentiellement relire le tutoriel original.
Citer : Posté le 04/05/2021 20:27 | # |
Fichier joint
@Ninestars J'ai commencé à regarder pour compiler libstdc++. Mais ça dépend de beauuucoup de trucs dans la lib standard. Ce sera probablement un grind avant que j'y arrive. Je ne sais pas encore quelles sont les options, le plus direct pourrait être par exemple de ressortir newlib... c'est clairement un problème ouvert.