gint : un noyau pour développer des add-ins
Posté le 20/02/2015 17:30
Ce topic fait partie de la série de topics du fxSDK.
En plus des options de programmation intégrée comme le Basic Casio ou Python, la plupart des calculatrices Casio supportent des
add-ins, des programmes natifs très polyvalents avec d'excellentes performances. Les add-ins sont généralement programmés en C/C++ avec l'aide d'un ensemble d'outils appelé SDK.
Plusieurs SDK ont été utilisés par la communauté avec le temps. D'abord le
fx-9860G SDK de Casio avec fxlib pour Graph monochromes (plus maintenu depuis longtemps). Puis le
PrizmSDK avec libfxcg pour Prizm et Graph 90+E (encore un peu actif sur Cemetech). Et plus récemment celui que je maintiens, le
fxSDK, dont gint est le composant principal.
gint est un unikernel, ce qui veut dire qu'il embarque essentiellement un OS indépendant dans les add-ins au lieu d'utiliser les fonctions de l'OS de Casio. Ça lui permet beaucoup de finesse sur le contrôle du matériel, notamment la mémoire, le clavier, l'écran et les horloges ; mais aussi de meilleures performances sur le dessin, les drivers et la gestion des interruptions, plus des choses entièrement nouvelles comme le moteur de gris sur Graph monochromes.
Les sources de gint sont sur la forge de Planète Casio :
dépôt Gitea Lephenixnoir/gint
Aperçu des fonctionnalités
Les fonctionnalités phares de gint (avec le fxSDK) incluent :
- Toutes vos images et polices converties automatiquement depuis le PNG, sans code à copier (via fxconv)
- Un contrôle détaillé du clavier, avec un GetKey() personnalisable et un système d'événements à la SDL
- Une bibliothèque standard C plus fournie que celle de Casio (voir fxlibc), et la majorité de la bibliothèque C++
- Plein de raccourcis pratiques, comme pour afficher la valeur d'une variable : dprint(1,1,"x=%d",x)
- Des fonctions de dessin, d'images et de texte optimisées à la main et super rapides, surtout sur Graph 90+E
- Des timers très précis (60 ns / 30 µs selon les cas, au lieu des 25 ms de l'OS), indispensables pour les jeux
- Captures d'écran et capture vidéo des add-ins par USB, en temps réel (via fxlink)
Avec quelques mentions spéciales sur les Graph monochromes :
Un moteur de gris pour faire des jeux en 4 couleurs !
La compatibilité SH3, SH4 et Graph 35+E II, avec un seul fichier g1a
Une API Unix/POSIX et standard C pour accéder au système de fichiers (Graph 35+E II seulement)
Et quelques mentions spéciales sur les Graph 90+E :
Une nouvelle police de texte, plus lisible et économe en espace
Le dessin en plein écran, sans les bordures blanches et la barre de statut !
Un driver écran capable de triple-buffering
Une API Unix/POSIX et standard C pour accéder au système de fichiers
Galerie d'add-ins et de photos
Voici quelques photos et add-ins réalisés avec gint au cours des années !
Arena (2016) — Plague (2021)
Rogue Life (2021)
Momento (2021)
Communication avec le PC (cliquez pour agrandir)
Utiliser gint pour développer des add-ins
Les instructions pour installer et utiliser gint sont données dans les divers tutoriels recensés dans le
topic du fxSDK. Il y a différentes méthodes de la plus automatique (GiteaPC) à la plus manuelle (compilation/installation de chaque dépôt). Le fxSDK est compatible avec Linux, Mac OS, et marche aussi sous Windows avec l'aide de WSL, donc normalement tout le monde est couvert
Notez en particulier qu'il y a des
tutoriels de développement qui couvrent les bases ; tout le reste est expliqué dans les en-têtes (fichiers
.h) de la bibliothèque que vous pouvez
consulter en ligne, ou dans les ajouts aux changelogs ci-dessous.
Changelog et informations techniques
Pour tester les fonctionnalités et la compatibilité de gint, j'utilise un add-in de test appelé gintctl (
dépôt Gitea Lephenixnoir/gintctl). Il contient aussi une poignée d'utilitaires d'ordre général.
Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et des liens vers des instructions/tutoriels supplémentaires qui accompagnent ces versions.
Anecdotes et bugs pétés
Ô amateurs de bas niveau, j'espère que vous ne tomberez pas dans les mêmes pièges que moi.
TODO list pour les prochaines versions (2023-04-03)
gint 2.11
- Changements de contextes CPU. À reprendre du prototype de threading de Yatis pour permettre l'implémentation d'un véritable ordonnanceur. Demandé par si pour faire du threading Java.
- Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
- Support de scanf() dans la fxlibc. Codé par SlyVTT, plus qu'à nettoyer et fusionner.
Non classé
- Regarder du côté serial (plus facile que l'USB) pour la communication inter-calculatrices (multijoueur) et ultimement l'audio (libsnd de TSWilliamson).
- Un système pour recompiler des add-ins mono sur la Graph 90+E avec une adaptation automatique.
- Support des fichiers en RAM pour pouvoir utiliser l'API haut-niveau sur tous les modèles et éviter la lenteur de BFile à l'écriture quand on a assez de RAM.
Citer : Posté le 01/08/2019 14:04 | #
Ben j'ai ouvert l'image en question et j'ai fait Couleur vers Alpha, et j'ai pris Blanc… Du coup le blanc est devenu transparent… C'est pas comme ça qu'il faut faire ?
Citer : Posté le 02/08/2019 16:58 | #
Tu fais ça et tu exportes en PNG. Si tu as une erreur de fxconv c'est probablement un problème avec PIL. Je veux bien voir le message.
(De façon générale quand tu as une erreur avec une message, tu DOIS donner le message. Même pas besoin de poser la question. >_>)
Citer : Posté le 02/08/2019 17:00 | #
Quand j'essaye de make "libprof", j'obtient une erreur me disant que "tmu.h" ne se trouve pas dans le dossier ce qui est vrai mais je ne sais pas comment l'ajouter...
libprof.c:3:10: fatal error: gint/mpu/tmu.h: No such file or directory
#include <gint/mpu/tmu.h>
^~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:28: build/libprof.c.o] Error 1
Citer : Posté le 02/08/2019 17:02 | #
Il me semble que j'avais eu ça aussi, mais du coup j'ai directement mis les 2 fichiers dans le projet, et ça compile tout aussi bien
Citer : Posté le 02/08/2019 17:06 | #
merci du conseil mais tu sais pourquoi ça ne fonctionne pas ?
Citer : Posté le 02/08/2019 17:06 | #
Non
Ajouté le 02/08/2019 à 17:07 :
Mais jai reussi a le faire fonctionner quand même
Citer : Posté le 02/08/2019 18:12 | #
Ta version de gint est-elle à jour ? N'hésite pas à pull puis installer ; le fichier concerné est assez récent
Citer : Posté le 02/08/2019 18:27 | #
Bien vu
J'ai mis à jour gint et l'installation se fait maintenant sans problème
Citer : Posté le 04/08/2019 11:55 | # | Fichier joint
J'ai une super nouvelle ! Les premiers tests de bopti sur Graph 90+E commencent à fonctionner !
Malheureusement il n'y a pas de VRAM dense contrairement à la Graph 75, donc pas d'optimisations fulgurantes à réaliser. Disons que je vais fournir une implémentation décente des algorithmes ; et pour les images en 16-bit sans transparence j'ai un algo plus rapide que le naïf.
gint va supporter quatre formats d'image en couleurs !
• 16-bit classique "r5g6b5" ;
• 16-bit classique avec transparence (à condition qu'une des 65536 couleurs soit inutilisée) "r5g6b5a" ;
• 8-bit avec palette et transparence, "p8" ;
• 4-bit avec palette et transparence, "p4".
Pour l'instant j'ai codé les deux premiers et ci-dessous c'est un test du premier ! Attention par contre, je pense que ça prend bien 10 ms pour l'afficher, autrement dit c'est lent... il y a du travail à faire pour être capable de faire des frames très rapides (Ici, un coup de dma_memcpy() est certainement la meilleure solution.)
Citer : Posté le 04/08/2019 12:05 | #
Vachement stylé !
D'ailleurs, je ne me suis toujours pas repenché sur le dma, mais je vais probablement le faire d'ici quelques jours (procrastination )
Citer : Posté le 04/08/2019 13:06 | #
Whaaaaaaa
Je cours m'acheter une 90+e de suite pour télécharger les add-ins AAA qui vont sortir sur ce support.
Citer : Posté le 04/08/2019 13:14 | #
Alors ça...c'est époustouflant. J'ai clairement dû rater plusieurs infos...
Je suis plus qu'impatient d'installer tout ça une fois que je serai sous Linux!
(*se frotte les mains en laissant s'échapper un petit rire diabolique*)
Par contre je ne comprends pas les formats d'images. Comment sont-ils générés?
Citer : Posté le 04/08/2019 13:45 | #
C'est dispo quand ?
Citer : Posté le 04/08/2019 13:56 | # | Fichier joint
C'est dispo quand ?
Dès que j'aurai poussé les modifications sur le dépôt... disons ce soir !
Et je suis content d'annoncer que sans aucune modification du code la transparence marche également !
À ce stade le seul problème restant étant que les images sont grosses donc il est important d'implémenter les palettes 8 bits et 4 bits.
J'ai programmé l'application pour que les flèches permettent de déplacer les images des épées, et j'ai remarqué que le programme prend légèrement du retard, autrement dit il n'arrive pas à dessiner aussi vite que les événements claviers sont produits. Il est donc un peu en-dessous de 25 FPS.
Eh oui, pour un affichage aussi simple c'est déjà pas facile. Je vais donc me pencher sur notre meilleure arme jusqu'ici, le DMA ! Il permet en effet de copier de la mémoire en parallèle et pendant qu'on fait autre chose. Ce sera l'occasion d'intégrer et compléter la pull request de Milang.
Ajouté le 04/08/2019 à 14:17 :
Bon, j'ai poussé tout ce que j'ai fait jusqu'à présent, donc le code est en fait disponible maintenant.
▾ Note importante : vous devrez modifier vos Makefile lorsque vous mettrez à jour le fxSDK ! ▾
Quand vous créez un projet avec fxsdk, il génère un Makefile mais n'y touche plus jamais ensuite. Vous devez faire les modifications à la main... et il y en a une aujourd'hui !
L'ancien Makefile généré par fxsdk contient les lignes suivantes :
build-fx/assets/img/%.o: assets-fx/img/%
@ mkdir -p $(dir $@)
fxconv -i $< -o $@ name:img_$(basename $*)
build-cg/assets/img/%.o: assets-cg/img/%
@ echo -ne "\e[31;1mWARNING: image conversion for fxcg50 is not "
@ echo -ne "supported yet\e[0m"
@ mkdir -p $(dir $@)
fxconv -i $< -o $@ name:img_$(basename $*)
Il faut les remplacer par les lignes suivantes.
build-fx/assets/img/%.o: assets-fx/img/%
@ mkdir -p $(dir $@)
fxconv -i $< -o $@ --fx name:img_$(basename $*)
build-cg/assets/img/%.o: assets-cg/img/%
@ mkdir -p $(dir $@)
fxconv -i $< -o $@ --cg name:img_$(basename $*)
Même si vous ne faites pas le changement tout de suite, vous pourrez quand même compiler. Mais si vous voulez utiliser des images pour Graph 90+E ou simplement être à jour, faites-la au plus vite !
Citer : Posté le 04/08/2019 14:43 | # | Fichier joint
On m'a demandé mon g3a, et c'est vrai que je pourrais le partager plus souvent ! Le voici en pièce jointe.
L'application en question est gintctl, un add-in de test pour gint et d'introspection pour la machine, que je développe en même temps pour m'aider à debugger. La moitié des fonctions est encore absente !
Pour cette fois, c'est dans "Image rendering". Enjoy!
Note : l'addin fait 250k car l'image en plein écran prend 170k... eh oui x_x
Citer : Posté le 04/08/2019 16:31 | #
C'est joli !
(Intéressant comme remarque...)
En mode d'affichage, ça peut paraître un peu bête mais pourrais tu essayer d'implémenter un mode 1-bit ?
J'adore créer des jeux en blanc sur noir, et l'économie d'espace serait énorme
Dans la même veine, une implémentation grayscale serait superbe ! Beaucoup de nuances d'une seule couleur rendrait très bien je pense et serait rentable niveau performances !
Dès que j'arrive à installer et comprendre gint, je me mets à coder un truc
Citer : Posté le 04/08/2019 16:44 | #
Je peux imaginer des images en 1-bit ou en niveaux de gris oui ! Toutefois, ça n'améliorera probablement pas beaucoup les performances... le problème c'est que la quantité de données à envoyer à l'écran est énorme et ça peu importe le format d'image que tu utilises. Il y a un mode réduit de l'écran avec 8 couleurs, mais très peu d'usages pour le coût d'implémentation...
Merci en tous cas ! Je vous dis si j'arrive à faire quelque chose avec le DMA pour améliorer les performances.
Citer : Posté le 04/08/2019 17:29 | #
Beh, commence par faire des tests avec la libprof, on verra ce qui consomme le plus
Après si le DMA est fonctionnel, on ne peut que être gagnant, mais faut voir combien de temps ça fait gagner sur une frame de calcul. Tant que le calcul reste plus rapide on est bon, et si le DMA plafonne à 30 fps c'est déjà largement suffisant dans la majorité des cas.
Citer : Posté le 04/08/2019 18:23 | #
Oui, oui, certes ! Mais je vois bien que c'est le dessin le problème puisque j'ai 40 ms de délai et qu'il en prend donc manifestement au moins 25 ms.
Le problème est le suivant : s'il faut 25 ms pour afficher ta map en arrière-plan, tu as épuisé le budget de ton frame sans même avoir dessiné les personnages, les effets spéciaux, et calculé la physique et les IAs. C'est vachement short !
Il reste toujours l'overclock mais moins on en met et mieux les piles se portent.
Citer : Posté le 06/08/2019 13:26 | # | Fichier joint
J'ai constaté quelque chose que je trouve étrange (c'est peut être voulu) au sujet des images pour calculatrice monochrome :
lors de la conversion d'une image avec transparence, j'ai l'impression que certains pixels sont "ignorés" :
Dans le cas d'une image avec la première colonne de transparente, cette colonne semble disparaître
Il se peut que ce soit aussi le cas avec les lignes
Le "problème" est que lorsque j'utilise dsubimage avec flags=0 pour afficher le bon sprite associé à un item, mon image est décalée et ne ressemble plus à rien
Cela vient-il de fxconv, du format d'image de gint ou de l'argument flags ?
Pour certains sprites j'ai mis du blanc en arrière plan et le problème était résolu, mais pour le brouillard de guerre je ne peux pas le faire
EDIT : En fait, j'ai l'impression qu'il y a un décalage qui se crée avec la suppression de certains pixels et pas d'autres
Citer : Posté le 06/08/2019 16:19 | # | Fichier joint
Du côté de fxconv tout est bon, il ne supprime pas de ligne ou de colonne tant que tu ne spécifies un area sur la ligne de commande. Je viens de tester avec ton image, la première colonne est bien là.
Ce que tu décris doit marcher tout seul, c'était bien un bug dans l'algo de tracé ! (Un bug que j'avais déjà vu mais pas corrigé totalement, con comme je suis...) J'ai corrigé et poussé, Je te joins un g1a qui démontre le code fonctionnel ci-dessous et trace chaque élément de ton image indépendamment.
Merci de ta patience avec mon code encore jeune...
#include <gint/keyboard.h>
int main(void)
{
dclear(C_WHITE);
dtext(0, 0, "Sample fxSDK add-in.", C_BLACK, C_NONE);
extern image_t img_brouillard;
dimage(0, 9, &img_brouillard);
for(int i = 0; i < 16; i++)
{
dsubimage(4 + 16 * (i&7), 32 + 16 * (i>=8), &img_brouillard,
8 * i, 0, 8, 8, DIMAGE_NONE);
}
dupdate();
getkey();
return 1;
}