Posté le 15/07/2017 13:54
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 64 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 23/12/2020 18:40 | #
Super, je suis content que ça t'ait plu !
Puisqu'on est sous Linux tu peux simplement créer un lien symbolique d'un côté vers l'autre pour avoir le même dossier en double sans les inconvénients d'avoir une copie :
Mais c'est vrai qu'on peut sans doute mieux organiser les dossiers dans cette histoire... je reverrai le système de build dans une prochaine révision majeure du fxSDK (celle qui introduit le gestionnaire de dépôts) donc si tu as des suggestions je suis preneur.
Citer : Posté le 23/12/2020 19:04 | #
J'aime pas trop le lien symbolique dans les sources mais ça suffira pour le moment, merci
Je pensais à un dossier assets pour les fichiers partagés avec le système actuel, ça me semble cohérent avec le reste.
Sinon pour la cohésion avec le gestionnaire de dépôts j'aime bien ce genre d'organisation :
assets
|
+-+ project-name
| |
| +-- shared
| |
| +-- fx
| |
| +-- cg
|
+-+ lib-name
|
+-- shared
|
+-- fx
|
+-- cg
Bonne soirée
Citer : Posté le 23/12/2020 19:58 | #
Hmm... tiens je m'y attendais pas à ça. Partagés entre quoi exactement ? Parce que si c'est entre plusieurs projets ça risque d'être compliqué à pousser sur des dépôts. Je pense pas avoir compris entièrement ce que tu imagines, donc je voudrais bien quelques détails en plus.
Citer : Posté le 23/12/2020 23:19 | #
Le tutoriel me semble complet, et comme à chaque fois me met l'eau à la bouche !
J'aimerais savoir si il est compatible avec la 90+E après quelques adaptations (assets etc.) ?
Citer : Posté le 23/12/2020 23:24 | #
Aaaah putain excellente idée.
Bah écoute je viens de le faire. Il suffit de tout mettre dans assets-cg et de remplacer ce C_INVERT par un truc compatible, et ça marche instantanément exactement comme le jeu d'origine. x)
Ah j'y avais jamais pensé et j'avoue que ça fait plaisir.
J'ajouterai le support de C_INVERT un de ces jours. J'aimerais bien avoir un jeu de couleurs plus consistant entre les deux plateformes.
Citer : Posté le 23/12/2020 23:30 | #
Juste ça ? o___o
Demain j'aurai de quoi m'occuper alors, merci
Citer : Posté le 25/12/2020 18:47 | #
Hello.
N'y aurait-il pas un problème avec dtext sur la 90 + E avec la dernière version de gint ? Un code que j'avais fait aux dernières vacances, provoque, recompilé, un reboot de la calculatrice, et plus généralement, un dtext, même celui du code donné en exemple par fxsdk à la création du projet donne un reboot à l'exécution....
Citer : Posté le 25/12/2020 19:10 | #
Le fonctionnement de dtext a changé avec gint 2.0, c'est sûrement la cause de ton problème.
https://gitea.planet-casio.com/Lephenixnoir/gint/src/branch/master/include/gint/display.h#L307
Citer : Posté le 25/12/2020 19:27 | #
Installe la branche dev de gint si tu as un doute, ça résout souvent des problèmes (à mon grand dam, parce que ça montre que je gère pas la branche master correctement >_>)
Citer : Posté le 25/12/2020 19:41 | #
Merci, ça fonctionne! :-D
Citer : Posté le 25/12/2020 19:48 | #
Encore désolé pour la gestion chaotique des branches, je promets d'adopter un modèle plus sérieux (j'y travaille). >_>
Citer : Posté le 25/12/2020 21:39 | #
Salut! J'ai juste une petite question: est-ce qu'il existe un certain émulateur pour pouvoir tester des add-ins faits avec Gint?
Citer : Posté le 25/12/2020 21:45 | #
Les émulateurs Graph 35+E II et Graph 90+E sont officiellement supportés.
Citer : Posté le 25/12/2020 21:50 | #
Ah parfait, merci beaucoup!!
Citer : Posté le 26/12/2020 11:13 | #
Hmm... tiens je m'y attendais pas à ça. Partagés entre quoi exactement ? Parce que si c'est entre plusieurs projets ça risque d'être compliqué à pousser sur des dépôts. Je pense pas avoir compris entièrement ce que tu imagines, donc je voudrais bien quelques détails en plus.
Désolé pour le temps de réponse j'ai visiblement raté ce message
Je commence par le shared, c'est le meilleur terme que j'ai trouvé pour fx+cg, mais je pense qu'il n'y a pas de raisons pour que certaines parties soient utilisées par plusieurs projets en même temps (surtout pour les assets graphiques).
Je pensais à séparer les ressources en plusieurs "modules" (dossiers), et peut-être importer les ressources avec un préfixe lié au nom du module à la manière de Minecraft. Hum si je ne suis pas clair désolé.
Citer : Posté le 26/12/2020 11:33 | #
Perso je serais naturellement parti vers un truc de ce type :
├── assets
│ ├── cg
│ │ ├── fonts
│ │ └── img
│ ├── fx
│ │ ├── fonts
│ │ └── img
│ └── maps
└── src
Ou éventuellement avec un niveau de plus via shared
├── assets
│ ├── cg
│ │ ├── fonts
│ │ └── img
│ ├── fx
│ │ ├── fonts
│ │ └── img
│ └── shared
│ └── maps
└── src
Citer : Posté le 26/12/2020 11:39 | #
Hmm je vois. Je réfléchis en même temps à une façon plus propre de spécifier les paramètres que via project.cfg. (À l'origine, le scripting de fxconv par Python était supposé servir à ça, puis ça a dérivé au fil du temps.)
Je me dis que si on peut spécifier les paramètres proprement par dossier ou fichier, il n'y a pas trop de raison de séparer fx et cg : il suffit d'utiliser un paramètre pour dire sur quelle plateforme l'asset est pertinent.
Dans l'ensemble KikooDX me laisse penser que restreindre moins la forme du répertoire serait bien, surtout dans le cas où il y a des ressources qui sont normalement pas dans le dossier. Par exemple ce serait bien si on pouvait installer uf5x7 hors du projet et s'en servir quand même. Jusqu'ici je pensait simplement précompiler les assets en une lib statique, mais ça permet pas de spécifier des paramètres de conversion.
Si je pars sur un changement de structure, porter les projets sera un peu plus tordu et sans doute pas automatique. Donc je voudrais m'assurer de ne le faire qu'une fois en même temps que je mets à jour la méthode d'installation de dépôts avec le fxSDK, sinon tout le monde va vite en avoir marre. ^^"
En tous cas merci, vous me donnez des bonnes idées ! <3
Citer : Posté le 26/01/2021 15:07 | #
j'ajoute le support des timers pour mon moteur et j'ai ça:
56 | int t = timer_setup(TIMER_ANY, ENGINE_TICK*1000, callback_tick, &tick);
| ^~~~~~~~~~~~~
| |
| int (*)(volatile int*)
pourtant j'ai bien suivit le tuto
Ajouté le 26/01/2021 à 15:10 :
je vois qu'il demande une variable et plus une fonction, il y a eut une mis a jour?
Citer : Posté le 26/01/2021 15:17 | #
C'est un problème un peu subtil, mais voilà les grandes idées. timer_callback_t est un type qui liste les fonctions autorisées pour timer_setup(). Tu peux voir dans la liste que la fonction doit renvoyer un int et prendre en paramètre soit rien, soit un void *, soit un int * (modulo qualifieurs).
Le compilateur se plaint que tu as voulu passer en argument une fonction qui renvoie un int et prend en paramètre un int *, prétextant que ce type n'est pas autorisé dans la liste.
Le type est bel et bien autorisé dans la liste, mais je l'ai ajouté plus récemment que les autres. Je soupçonne que ta version de gint date d'avant ce changement, à l'époque où il n'était pas encore autorisé.
Mets donc à jour gint puis recompile avec make -B, je pense que ça devrait suffire.
Citer : Posté le 26/01/2021 15:53 | #
je suis sous la branche dev et il faut compiler avec cmake il est écrit que fxsdk sais le compiler mais ça marche pas!
il faut aussi le mettre a jour?
Citer : Posté le 26/01/2021 16:00 | #
Ah ! Tu pourrais obtenir la compilation avec CMake en utilisant la branche dev du fxSDK. Mais comme tu n'as (je pense) pas besoin de toutes les nouveautés juste quand elles sortent, tu peux faire plus simple et utiliser la branche master partout (donc git checkout master dans gint et ensuite tu réinstalles). La branche master te donne les releases donc tu seras sûr d'éviter les dé-synchronisations entre les différents outils.
(Dans le passé je n'ai pas toujours bien géré ça et c'est sans doute pour ça que tu es sur dev. Je fais plus attention maintenant, promis !)