fxSDK, un SDK alternatif pour écrire des add-ins
Posté le 29/08/2014 22:00
Cette page sert d'index pour la série de topics du fxSDK.
Le fxSDK est une collection d'outils permettant de développer des add-ins pour les calculatrices Casio des séries Graph. C'est une alternative au
fx-9860G SDK et
PrizmSDK qui ne sont plus activement maintenus, et le compagnon classique de mon noyau
gint.
Index des topics
Ce projet existe depuis 2015, alors il y a pas mal de topics liés. En voici une liste complète !
Topics principaux
Installation du fxSDK
Tutoriels
Compatibilité sur calculatrice et PC
Côté PC, le fxSDK est compatible avec
Linux, Mac OS, et WSL pour Windows ; normalement tout le monde peut l'utiliser. Je teste constamment sous Linux, et WSL est un Linux donc c'est testé aussi. Je n'ai pas de Mac OS donc il peut y avoir quelques surprises, mais en général c'est l'affaire de corriger un bug ou deux.
En termes de calculatrices, le fxSDK supporte :
Calculatrices monochromes
Graph 35+E II
Graph 35+ USB / Graph 35+E (SH3/SH4)
Graph 75/75+/75+E
Graph 85/85 SD/95 (SD) (pas activement testé)
Calculatrices couleurs
Graph 90+E / fx-CG 50
Prizm fx-CG 10/20
Comment installer le fxSDK et coder des add-ins
Le fxSDK s'installe à partir de dépôts Git sur la
forge de Planète Casio (par exemple
Lephenixnoir/fxsdk). Il y en a un peu beaucoup, donc manuellement c'est assez long. Pour que ça aille plus vite et pour simplifier le travail des débutants, il y a un outil appelé
GiteaPC qui peut faire ça pour vous.
Si vous utilisez Windows, vous aurez besoin de WSL pour accéder à un système Linux dans Windows. Heureusement, Microsoft a fait ça bien et c'est facile à faire. Voyez le
tutoriel d'installation de WSL 2 (et l'explication rapide de
ce que WSL 2 est).
Si vous utilisez Mac OS, ouvrez l’œil en lisant les topics pour ne pas manquer les informations supplémentaires et éventuelles déviations par rapport à la procédure normale sous Linux.
Méthode automatique avec GiteaPC (plus rapide / recommandée pour les débutants)
- Suivez le tutoriel d'utilisation de GiteaPC, qui explique comment obtenir le fxSDK.
Méthode automatique avec plugin VS Code
- Yannis300307 a créé un plugin VS Code Casio Dev Tools qui fonctionne sous Windows (avec WSL) et Debian (probablement les dérivés aussi).
Méthode AUR pour les utilisateurs Arch/Manjaro/dérivés (ils se reconnaîtront)
- Dark Storm maintient MiddleArch, un dépôt de paquets précompilés qui a entre autres le fxSDK.
Méthode manuelle (plus fine / classique pour les habitués)
- Compilez et installez le cross-compilateur GCC pour SuperH.
- installez (dans cet ordre) les dépôts fxSDK, OpenLibm, fxlibc, gint ; en option, Slyvtt/µSTL_2.3.
Description sommaire du fxSDK
Pour une introduction à l'utilisation du fxSDK qui montre comment utiliser les outils pour développer un add-in, lisez plutôt les
tutoriels d'utilisation de gint. Cette section est juste une description sommaire.
Le cœur du fxSDK est un cross-compilateur GCC pour SuperH, habituellement nommé
sh-elf-gcc. Bien sûr on a avec toute la suite d'outils, dont
as,
ld,
objdump,
objcopy (entre autres). Contrairement au vieux compilateur du SDK, GCC est un compilateur moderne avec beaucoup d'options et capable de très solides optimisations.
Sur la calculatrice, c'est
le noyau gint qui fait la majorité du travail. Il remplace fxlib/libfxcg et une partie de l'OS pour vous offrir des fonctionnalités plus cool et plus rapides. Les add-ins développés avec le fxSDK utilisent gint toutes les trois lignes !
Il y a enfin plusieurs outils utiles sur le PC qui sont utilisés durant le développement ou l'utilisation des add-ins :
- fxsdk est un script shell qui permet de créer et compiler les projets sans se prendre trop la tête. Le système de compilation officiel pour les add-ins est CMake, mais un système plus ancien de Makefile est encore supporté.
- fxconv est un outil très polyvalent qui convertit à la compilation les assets (images, polices, maps....). Il permet de travailler avec des logiciels et formats de fichiers normaux sur le PC et d'avoir automatiquement un format optimisé sur la calculatrice. fxconv est extrêmement extensible et chaque projet peut ajouter des conversions personnalisées.
- fxgxa crée les fichiers g1a (format des add-ins pour Graph monochromes) et g3a (format des add-ins pour Graph couleurs) à partir des programmes compilés.
- fxlink est un outil de communication qui peut transférer des fichiers vers les Graph 35+E II et Graph 90+E en ligne de commande, mais aussi échanger interactivement avec les add-ins gint par le câble USB, et est couramment utilisé pour réaliser des captures d'écran ou captures vidéo des add-ins.
Changelog et informations techniques
Ci-dessous se trouve la liste des posts annonçant les nouvelles versions du fxSDK, ainsi que des liens vers les instructions/tutoriels supplémentaires publiés avec.
Citer : Posté le 11/07/2019 14:19 | #
Buh… J'ai pas de map avec Tiled…
Toi non mais les autres personnes de l'équipe ne codent pas les maps en hexadécimal ! Et tu ne vas pas les convertir à la main... d'abord parce que c'est chiant et le risque d'erreur est élevé, et ensuite parce que ça te fera des duplications puisque les originaux seront sur le dépôt.
La méthode de Cake est exactement là où je voulais en venir.
Okay, donc les maps peuvent être enregistrées comme ça… ?
Essaie de te familiariser avec l'idée que les données c'est juste une suite d'octets. Ta matrice est une suite d'octets. Si tu apporte ces octets dans la mémoire, tu as une matrice.
Tu connais normalement deux façons de faire ça :
1. Faire un tableau
2. Créer un fichier qui contient ces octets et utiliser fxconv
-
Je fais une parenthèse pour considérer un autre cas : les images. Comme tu l'as vu dans le tutoriel d'utilisation de gint, les images sont converties automatiquement par fxconv. C'est pratique parce qu'il n'y a plus de Sprite Converter et plus de tableau à écrire à la main. Mais surtout c'est nécessaire parce que tu ne pourrais pas convertir à la main et créer un tableau : le format est beaucoup trop compliqué.
-
Ta map est toujours une matrice, les octets sont juste apportés par fxconv au lieu de te donner un tableau à écrire. Quant aux dessins, tu auras une grande image de tout le tileset qui sera convertie automatiquement et tu appeleras dsubimage() pour afficher un tile à chaque fois.
Mais c'est exactement ce que tu auras parce que le fichier créé par fxconv va contenir exactement la matrice que tu aurais écrite. Sauf qu'elle aura été écrite à ta place, avec plusieurs avantages :
1. L'action de calculer les valeurs pour la matrice à partir de la map sera automatisée (avec un script, comme Cake a dit)
2. Si un tile bouge sur le tileset, il suffira de reconvertir au lieu de devoir changer tous les numéros de ce tile à la main
3. Sur le dépôt il n'y aura qu'une version de la map : l'originale avec Tiled. Avoir deux versions (Tiled et le tableau) c'est risquer qu'il y a des différences entre les deux
4. Le concepteur de maps peut utiliser un outil agréable
Et ok, toi tu utilises peut-être pas Tiled. Pour tester ton rendu de map tu peux totalement faire un tableau, à la limite on s'en fout. Mais la personne de l'équipe d'Odyssée qui fait la map n'aura clairement pas envie de se taper une syntaxe aussi barbare que des numéros les uns à la suite des autres sans rendu visuel, et pour les vraies maps en production il faut prendre le temps de le faire correctement.
Bien sûr tu ne regardes pas le dessin, tu as toujours ta matrice avec les numéros que tu as annoncés, donc si c'est 1 (mur) ou 2 (PNJ) on lance interact() et si c'est 3 (porte) on lance maisons(). Tu as forcément à la fois la map d'un côté (la matrice) et le tileset de l'autre (les images).
Mais avec Tiled, toutes la map est affiché comme une image (de ce que j'ai compris…
Aaaah, mais non. Tiled gère la map comme une matrice. Mais il te permet de voir la map pendant que tu la crées ! C'est pour ça que généralement t'as envie de l'utiliser : tu peux voir au fur et à mesure à quoi ça va ressembler.
Faire une map entièrement sur une image ce serait pas efficace du tout (et puis si deux tiles ont la même tête...).
J'en profite pour rajouter que quand tu exportes la map avec Tiled il va te mettre des numéros qui correspondent en gros à la position du tile dans ton tileset : c'est pour ça qu'il est important que le tileset bouge pas trop (ou en tout cas que les tiles utilisés restent à leur place). Après tu utilises un script pour créer la matrice dans un fichier à partir du fichier Tiled, tu appelles fxconv sur le fichier ce qui créer la matrice comme une variable, et à la prochaine compilation la variable sera disponible.
Tout ça est tellement automatisable qu'il suffira de réenregistrer le fichier dans Tiled et de taper fxsdk build-fx et hop, l'add-in est recompilé avec la nouvelle map.
Mais pour afficher la map dans gint ?
Tu auras deux variables : la map et le tileset. Pour afficher la map, tu fais une boucle pour parcourir toutes les cases visibles et tu récupères leur numéro. À partir du numéro tu calcules la position du tile associé dans l'image du tileset. Puis tu appelles dsubimage() pour afficher la partie correspondante.
Citer : Posté le 11/07/2019 14:27 | #
Je crois qu'on s'est pas compris…
Citer : Posté le 11/07/2019 14:30 | #
Effectivement, on s'est mal compris, on te parles d'automatisée la création de cette matrice sur laquelle tu boucle
Citer : Posté le 11/07/2019 14:33 | #
Ah ben voila, on parle pas de l'affichage qui reste la même technique quelques soit la méthode de génération de la map.
En parlant de ça va falloir gazer, j'ai fais les premiers plans du monde sur une page A4, je suis à 14,5 cm par 14,5 grosso modo et j'ai estimé que les maps devraient faire environ 5mm par 5mm >_<' Ce qui fait un monde de 30 map par 30 soit environ 900 mas à designer…
Citer : Posté le 11/07/2019 14:36 | #
t'es pas obligée de tous les faire après, par exemples il pourrait y avoir des zones inaccessibles dan les forêts, etc ...
Citer : Posté le 11/07/2019 14:40 | #
C'est pas bête…
Je repense à mes maps : je dessine la maps sur tiled je l'exporte en CSV et je l'importe dans mon projet via fxconv en extern const int map[] et j'affiche normalement grâce au correspondance numéro/dessins générée par fxconv ?
Citer : Posté le 11/07/2019 14:42 | #
Le CSV c'etait juste pour que tu puisse facilement le lire sur ton ordis
Citer : Posté le 11/07/2019 14:43 | #
Je repense à mes maps : je dessine la maps sur tiled je l'exporte en CSV et je l'importe dans mon projet via fxconv en extern const int map[] et j'affiche normalement grâce au correspondance numéro/dessins générée par fxconv ?
Presque, presque. fxconv est assez fainéant, il te donne exactement les octets du fichier sans conversion. Donc si tu "convertis" le CSV avec fxconv tu auras l'équivalent d'une chaîne de caractères contenant "1,5,8,2,3" au lieu d'avoir une matrice donc chaque élément est un nombre.
Il faut faire un petit coup de conversion avant, en Python probablement. Si tu me donnes un exemple de fichier CSV de Tiled je veux bien faire ce script pour t'économiser du temps.
Et j'insiste, ta map ne doit pas être une matrice d'int parce que ça rentrera jamais dans la mémoire ! 900 tableaux (écrans) d'int ça fait 460'000 octets et la taille limite de l'add-in c'est 512'000. Tu ne peux pas te permettre de faire ça !
Citer : Posté le 11/07/2019 14:47 | #
C'est pas faux… xD Il y aurai quoi comme type moins gros ? unsigned char ?
Je vais essayer de te faire un exemple de fichier csv alors
Citer : Posté le 11/07/2019 14:50 | #
Pour en revenir à ce que je disais, la map de Pokémon Or et Argent par exemple, qui est immense, s’avère être un vrai gruyère quand on s'éloigne
Citer : Posté le 11/07/2019 14:51 | #
C'est vrai que je peux 'creuser' la mienne aussi pas mal
Citer : Posté le 11/07/2019 17:24 | #
Oui, très bon choix. Le type le plus propre serait uint8_t ce qui veut dire littéralement « entier non signé sur 8 bits », dont les valeurs vont de 0 à 255. Il faut donc s'arranger pour qu'un tileset ne contienne pas plus de 255 tiles différents. Bien sûr tu peux changer discrètement de tileset d'une zone à l'autre du monde...
Citer : Posté le 11/07/2019 17:27 | #
Je ne pense pas dépasser les 256
Citer : Posté le 11/07/2019 17:29 | #
D'ailleurs, en même temps que le CSV, est-ce que tu peux me donner le format d'origine de Tiled ?
Citer : Posté le 11/07/2019 17:30 | # |
Fichier joint
Le CSV est en pièce jointe !
Tu as une ligne entièrement blanche en bas, c'est normal pour cette map-là, mais au total, les maps font bien 12 tiles par 8…
Citer : Posté le 11/07/2019 17:40 | #
Ça m'a l'air pas mal. Est-ce que je peux voir aussi le tileset (et le fichier Tiled correspondant au tileset s'il y en a un) ?
Citer : Posté le 11/07/2019 17:43 | #
Euh, j'ai importé les dessins un par un (c'est un peu long
Citer : Posté le 11/07/2019 18:01 | #
C'est bien ce que je me disais en lisant le texte de la map : il y a un fichier par tile...
Eh bien il va falloir se démerder pour faire un vrai tileset parce que sinon on ne pourra pas afficher tout ça proprement dans gint !
Je regarderai, ce soir si j'ai de la chance.
Citer : Posté le 12/07/2019 13:11 | #
J'ai pas très bien compris… En gros Tiled a besoin de tilset pour fonctionner et Gint aussi, mais je dois avoir les même ?
Citer : Posté le 12/07/2019 13:43 | #
J'ai pas très bien compris… En gros Tiled a besoin de tilset pour fonctionner et Gint aussi, mais je dois avoir les même ?
À moins que tu ais envies que ton personnage puisse marcher sur l'eau et traverser les murs, oui ça vaut mieux
Et pour Tiled, on ne peut pas selectionner plusieurs images, donc il faut faire un tilset comme tu nous a montré avec 1 pixel entre chaque élément et importer ce dessin-là c'est ça ?
Si Tiled accepte ce format (ce qui est probablement le cas) oui ça permettra d'utiliser le même format pour le tileset de Tiled et de Gint
Citer : Posté le 12/07/2019 13:44 | #
Ok, j'essaye !