Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un noyau pour développer des add-ins
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

gint : un noyau pour développer des add-ins

Posté le 20/02/2015 17:30

Les SDKs classiques pour écrire des add-ins sont le fx-9860G SDK de Casio avec fxlib (pour Graph monochrome) et le PrizmSDK avec libfxcg (pour Prizm et Graph 90+E). Voici mon alternative : le fxSDK avec gint, pour toutes les plateformes.

Contrairement à fxlib et libfxcg, qui appellent les fonctions de l'OS pour faire leur travail, gint est un noyau indépendant de l'OS qui exploite seul le matériel et le met à disposition de votre add-in. Il vous offre plus de finesse sur le contrôle du matériel, notamment le clavier, l'écran et les horloges, de meilleurs performances sur le dessin, les drivers et la gestion de interruptions, et des choses entièrement nouvelles comme le moteur de gris.

Toutes les sources de gint sont publiques et accessibles sur la forge de Planète Casio :

» Dépôt Gitea Lephenixnoir/gint «

Voici plus précisément ce que gint vous offre de nouveau :

• Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
• Des timers avec une précision de 60 ns, d'autres à 30 µs
• Toutes vos images converties automatiquement sans code à copier (plus de Sprite Coder)
• Des polices personnalisées
• Des fonctions de dessin, d'images et de texte fulgurantes et optimisées la main
• Mesurer les performance de votre code à la microseconde près (avec libprof)
• Le contrôle du matériel et des interruptions
• Plein de petites choses pratiques comme dprint(1, 1, "x=%d", x)

• (Graph monochrome) Un moteur de gris pour faire des jeux en 4 couleurs !
• (Graph monochrome) La compatibilité SH3 et SH4, avec le même fichier g1a.

• (Graph 90+E) Une nouvelle police de texte, plus lisible et économe en espace
• (Graph 90+E) Le dessin en plein écran, sans les bordures blanches et la barre de statut !
• (Graph 90+E) Un driver écran capable de triple-buffering

Le coût de tout ceci, c'est que vous avez une copie du code de gint dans votre add-in. Cela prend environ 20 ko de place (selon la quantité de fonctions que vous utilisez), soit à peu près comme le sprintf() de fxlib qui fait 18 ko !

Et voici quelques photos et captures d'écran !





Tester gint sur votre machine

La fin du portage vers la Graph 90+E signera la sortie de gint v2. L'add-in de test de l'application est désormais gintctl :

» Dépôt Gitea Lephenixnoir/gintctl «

En plus de tester les fonctionnalités de gint, cet add-in contient quelques outils permettant d'inspecter la machine, la mémoire, et les registres. Je le développe au fur et à mesure, et je posterai un protocole de test complet avec la sortie de la v2 !

Utiliser gint pour développer des add-ins

Normalement, vous avez besoin du fxSDK pour développer avec gint. Le fxSDK est compatible avec Linux et Mac OS, et on peut réfléchir à un portage sous Windows s'il y a vraiment des intéressés. Il faut l'installer en premier (et avoir un cross-compilateur GCC).

La procédure de compilation et d'installation de gint est décrite sur le README du dépôt, c'est du configure - make tout à fait banal.

Une fois que gint est installé sur votre système, voyez les tutoriels de développement pour avoir un aperçu de son fonctionnement. La plupart des choses sont expliquées dans les en-têtes (fichiers .h) de la bibliothèque que vous pouvez consulter en ligne, sur votre copie locale du dépôt, ou dans les dossiers d'installation du compilateur.

Obtenir la dernière version de gint après une mise à jour

Je pousse régulièrement des mises à jour de gint sur le dépôt du projet. Pour les télécharger, tapez git pull, puis recompilez et réinstallez gint avec make et make install.


Fichier joint


Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 37, 38, 39, 40, 41, 42 Suivante
Leno Hors ligne Membre Points: 282 Défis: 0 Message

Citer : Posté le 29/05/2020 21:59 | #


Avec cette commande, je n’ai pas besoin de tout réinstaller ?
Seid ihr das essen ? Nein ! Wir sind der Jaeger !
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 29/05/2020 22:04 | #


Moi a écrit :
C'est un troll, au cas où

Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Yatis En ligne Membre Points: 512 Défis: 0 Message

Citer : Posté le 29/05/2020 22:15 | #


Yatis, le problème c'est que sudo ne récupère pas les variables d'environnement (donc pas le PATH). Il faut vraiment rester en user.

Je sais, je voulais juste savoir s’il avait installé GCC (visiblement non donc il ne va pas allez bien loin sans) x)
@Leno: regarde ce tuto, bonne chance https://www.planet-casio.com/Fr/forums/topic12970-1-tutoriel-compiler-sous-linux-avec-un-cross-compilateur-gcc.html
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 29/05/2020 23:28 | #


Bon, c'est sûrement crade, mais quitte à avoir fait des paquets, autant ne pas les avoir faits pour rien.

Si vous voulez juste avoir une installation classique de la toolchain, autant passer par les PKGBUILDS de l'AUR.

Je setup une VM Debian histoire de voir comment ça peut marcher sous Debian, mais dans l'idée faudrait ce script

Puis récupérer les PKGBUILD sur l'AUR (cloner les dépots suivants)

- https://aur.archlinux.org/sh-elf-binutils-casio.git
- https://aur.archlinux.org/sh-elf-gcc-casio.git
- https://aur.archlinux.org/fxsdk-git.git
- https://aur.archlinux.org/gint-git.git
Éventuellement
- https://aur.archlinux.org/mkg3a.git

Je garantis rien, mais ça me parait être convenable vu les galères que certains peu habitués aux environnements unix rencontrent.

Si ça marche, je ferais un tuto plus propre.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 30/05/2020 08:57 | #


... mais du coup faut installer en root puisque c'est dans le dossier système, n'oubliez pas ça.
Leno Hors ligne Membre Points: 282 Défis: 0 Message

Citer : Posté le 30/05/2020 18:48 | #


Finalement, j'ai reset ma machine virtuelle et j'ai tout réinstallé proprement sans sudo mais j'ai un problème lors du make de gint:
leno@laptop:~/opt/gint/build.cg$ make -j4
-e > fxconv font8x9.png
Traceback (most recent call last):
  File "/home/leno/opt/sh-elf-2.34-9.3.0/bin/fxconv", line 6, in <module>
    import fxconv
  File "/home/leno/opt/sh-elf-2.34-9.3.0/bin/fxconv.py", line 9, in <module>
    from PIL import Image
ModuleNotFoundError: No module named 'PIL'
make: *** [Makefile:114: src/font8x9.png.o] Error 1

Seid ihr das essen ? Nein ! Wir sind der Jaeger !
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 30/05/2020 19:03 | #


Comme le message d'erreur l'indique... tu as besoin du module Python PIL. Il est utilisé en l'occurrence pour convertir la police par défaut dans un format approprié.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 30/05/2020 21:53 | #


Bon, question à la con niveau gestion de framerate.

J'ai un jeu potentiellement lourd en calcul (jusqu'à ~100~200 objets à l'écran), qui doit tourner à ~20 fps pour être jouable.

Je vois trois solutions :

1 → Faire une boucle qui tourne à fond et qui adapte le mouvement des objets à la vitesse du tick précédent.
Avantage : je risque pas de plantage, et si la calto est assez puissante j'augmente le framerate.
Inconvénient : j'inclus un tas d'opérations sur des flottants pour gérer de manière dynamique la vitesse de mes objets. Potentiellement plus lent

2 → Faire un timer à 20 Hz pour la physique + l'affichage, et gérer les évènements à coup de getkey dans une boucle infinie.
Avantage : le framerate censé être constant
Inconvénient : si j'overflow la période du timer (calcul trop long), je risque le crash

3 → Faire un timer à 20 Hz pour l'affichage, gérer physique + évènements dans une boucle infinie
Avantage : l'affichage est constant à 20 Hz, la physique est aussi réactive que possible.
Inconvénient : idem que n°1, sans le lag visuel.

Des avis sur la solution à adopter ? Je pense partir sur #2 et optimiser à fond pour pas que ça foire. Au passage, si en plus y'a une solution qui permet de garder la vitesse constante quelque soit le niveau d'overclock (juste augmenter les fps/tps), ça serait le feu
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 30/05/2020 21:59 | #


À mon avis la solution la plus simple est similaire, mais différente de toute ça. Je serais partant pour avoir la boucle principale qui fait dessin, gestion des entrées, simulation de la physique en boucle, sachant que (1) la simulation de la physique tient compte du temps réel écoulé depuis la simulation précédente, et (2) il y a un timer à 20 Hz pour limiter les FPS juste au cas où ça aille plus vite que prévu (le callback incrémente un compteur et chaque frame décrémente le compteur, s'il tombe en négatif tu sleep()).

Ça te donne la même contrainte que ta solution #1 mais si les calculs sont en point fixe y'a rien à craindre. Les perfs c'est vraiment tout sur l'affichage, 200 objets × 10 multiplications de plus par frame ça n'arrive pas à la cheville de 170k accès RAM pour générer les données graphiques.

La solution #2 ne crashe pas en cas de lenteur, mais les interruptions se succéderont sans jamais laisser les entrées clavier se faire gérer par le thread principal, donc tu perds les entrées, ce qui est inacceptable.

Pareil pour la solution #3, ça ne crashe pas non plus, mais si l'affichage est trop long ni la physique ni les événements ne pourrait être effectués donc ton jeu freeze complètement.

J'ai imaginé pas mal de variantes de ça à une époque, mais en fin de compte je ne conseille d'utiliser un timer que si tu veux absolument pas gérer le delta temporel dans le moteur physique. Et dans ce cas, tu mets que les entrées et la physique dans le timer. Ce serait la solution alternative. N'oublie pas que le timer a la priorité et doit rester le plus rapide possible, ce n'est surtout pas l'endroit où mettre la partie la plus sensible du système, qui est le dessin.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 30/05/2020 22:19 | #


Bon, du coup je vais faire plus simple, vu ce que tu me dis.

Je résume les quelques tests que j'ai fait, mais en gros afficher un fond + 2000 objets 8×8 à l'écran reste dans les 50 ms correspondants aux 20 Hz que je m'impose.

Vu que j'ai 10× moins d'objets à gérer, et que le calcul physique sera à priori pas 10× plus long que le dessin, autant tout mettre dans la même boucle : si la calto arrive à monter les FPS, tant mieux, ça n'en sera que plus agréable. Et potentiellement on pourra faire des concours de FPS à coup d'overclock (même si ça sera peut-être pas nécessaire )

D'ailleurs pour l'affichage des FPS, la libprof c'est adapté ou un peu overkill ?
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 30/05/2020 22:29 | #


Ça a l'air raisonnable. Pour le calcul des FPS, libprof est très bien ; si tu veux avoir une donnée un minimum précise tu finirais par recoder quasiment la même chose de toute façon.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 30/05/2020 23:18 | # | Fichier joint


Je suis perfectionniste : dfont supporte les polices autres que N&B ? Genre celle en PJ ?


Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 31/05/2020 09:00 | #


Hmm... non, malheureusement ! Mais ce serait une extension intéressant sur G90. Dans ce cas les glyphes seraient des bitmaps et la couleur du texte serait ignorée en général.

Ce que tu peux faire en attendant c'est convertir comme une image et faire une fonction de dessin de texte custom. Ou tu peux séparer en images individuelles si tu préfères, dans ce cas tu peux utiliser fxconv.Grid qui implémente la séparation des glyphes en grille comme dans la conversion des polices.

Ajouté le 31/05/2020 à 22:34 :
Deux bonnes nouvelles aujourd'hui !

1. J'ai enfin réussi à rendre BFile stable avec gint. Il faut faire attention à pas mal de choses quand on sort puis revient dans gint (notamment que le DMA soit pas en train de transférer des trucs, et que toutes les pages soient toujours dans le TLB), mais après un peu d'effort ça a fini par sortir. Je peux écrire des gros fichiers (1M) de façon fiable sans crash, donc c'est super !

2. J'ai enfin ajouté la génération de nombres aléatoires avec un générateur pas trop stupide, à savoir TinyMT. srand() et rand() sont dans <gint/std/stdlib.h> du coup.

En plus de ça, j'ai revérifié que tout marche sur SH3 et tout marche sur SH3.

Plus qu'à gérer le TLB, ce qui permettra enfin de monter la limite de taille des add-ins de 220k à 512k (Graph mono) ou 2M (Graph 90+E), et tout sera bon. C'est l'ultime pirouette technique dont gint a besoin pour faire de l'idée folle de remplacer le noyau du système à la volée une réalité bien tangible.

Ajouté le 01/06/2020 à 09:21 :
Avec tout ça, voici la prochaine release en beta sur la branche master: 2.0.1-beta

Si vous êtes toujours sur la branch compat (parce que vous avez clôné le dépôt il y a plus de 3 semaines), pensez à git checkout master pour la release, voire git checkout dev si vous voulez les versions de développement avec les fonctionnalités le plus vite possible.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 01/06/2020 15:51 | #


En plus de ça, j'ai revérifié que tout marche sur SH3 et tout marche sur SH3.

Question à la con, mais est-ce que ça t'intéresserais que je commence à écrire un addin de tests unitaires ? Ça peut aussi se faire dans gintctl.

Le projet commence à être conséquent, et un truc du genre permettrait de vérifier facilement qu'il n'y ait pas de non-régressions.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 01/06/2020 15:53 | #


C'est exactement le but de gintctl. Si tu vois des tests importants qui sont pas dedans, je prends les suggestions/PR avec plaisir.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 01/06/2020 15:58 | #


À ma connaissance gintctl ne déroule pas l'ensemble des tests de manière automatique. Tu peux potentiellement passer à coté d'effets de bord un poil chelous. Je regarde ce que je peux faire à ce niveau là.

Bon du coup je passerai le paquet gint-git sur la branche master en même temps que le passage à GCC 10. Ça évitera d'avoir à recompiler 2 fois gint.

Et dernière remarque, il est fort probable qu'une nouvelle lib fixed fasse son apparition dans l'écosystème. Vu que je suis un gros flemmard, je comptais faire les paquets AUR pour la libprof, libimg et potentiellement la libfixed. Deux options : 1. un paquet par lib, faut voir comment les nommer ; 2. un paquet qui installe tout d'un coup, probablement gint-devel. T'as une préférence ?
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 01/06/2020 16:09 | #


Tu peux pas vraiment dérouler les tests de façon automatique... comment veux-tu vérifier automatiquement qu'un timer de 1 seconde dure une seconde (configuration du CPG) ? Comment veux-tu vérifier les entrées clavier sans appuyer dessus à la main (ghosting) ? Comment tester le driver DMA sachant que si ça se plante vraiment l'add-in crashe et que si les données sont fausses ça se voit qu'à l'écran (écran Graph 90) ? Comment tester que les valeurs du moteurs de gris sont correctes ? Comment tester le retour au menu sachant qu'il faut une entrée de l'utilisateur pour revenir dans l'add-in ? Bref, tu vois un peu l'idée.

Le but reste de tester des bugs de drivers ou de noyau, avec en gros la démarche suivante :
1. Implémenter des outils dans lesquels on peut manuellement tester les drivers et les actions sensibles.
2. Implémenter un maximum d'écrans de visualisation parce que l'information est le nerf de la guerre. Tout doit être visualisable.
3. Pour les trucs automatisables (printf, memcpy et consorts par exemple), y'a des tests automatiques, bien que ce soit sous-développé.

Les tests unitaires de libs sont largement bienvenus dans l'onglet LIBS, par exemple j'ai 768 variantes de memcpy/memmove avec un test unitaire auto que je m'apprête à y ajouter. (On pourrait aussi vérifier automatiquement la sortie de TinyMT, mais bon soyons honnête ça va jamais bugger ça vu qu'on y touchera pas.) Les fixed par exemple ce serait parfait ici !

Hmm si c'est pour faire un paquet pour chaque lib, autant utiliser git. Je vois plus d'intérêt à avoir gint-devel (gint-devel-git ?) ou un truc du type. En fait j'ai un peu peur des collisions de noms dans le schmilblick aussi, genre libimg sur l'AUR ça pue un peu. Peut-être gint-libimg-git sinon.
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 01/06/2020 23:44 | #


Pour les très gros flemmards, j'ai créé le paquet AUR gint-devel-git.

Il comprend :
– un GCC spécial Casio à jour
– le fxsdk
– mkg3a
– gint
– la libprof
– la libimg

Et d'autres outils qui viendront par la suite.

Et au passage, sh-elf-gcc-casio est passé en version 10.1.0, et gint-git sur la dernière release
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 02/06/2020 08:21 | #


Niiice, merci beaucoup

Les dérivés de Arch sont maintenant officiellement les distros les plus faciles pour bosser avec gint :3

Ajouté le 11/06/2020 à 18:29 :
J'ai commencé à jouer avec la fonctionnalité cruciale manquant avant la prochain release (gint 2.1) : supporter un TLB rempli dynamiquement. En gros, l'add-in est chargé sélectivement en mémoire à travers un truc qu'on appelle le TLB. Un gros add-in (≥ 220k) ne peut pas être chargé entier d'un coup, et donc il est nécessaire de charger les bouts au fur et à mesure qu'ils sont utilisés quitte à décharger d'autres bouts au passage.

Jusque-là gint nécessite que l'add-in soit chargé entier et le TLB reste inchangé pendant toute l'exécution. Sauf que la limite de 220k est horrible sur Graph 90+E, sachant que le maximum technique est 2M. Donc je commence à chercher à créer et faire fonctionner des add-ins plus gros. Actuellement je fous une énorme image dans l'add-in (que je fais attention de ne pas charger sinon mes routines de dessin et mes drivers sont délaissés !) et donc je travaille avec un add-in à moitié chargé. C'est flippant. ^^"

Le remplissage du TLB qui permet de charger différentes parties de l'add-in ne peut être fait que par l'OS, donc c'est toujours un peu compliqué de savoir si ça va bien se passer. Je vous tiens au courant... :3
Yatis En ligne Membre Points: 512 Défis: 0 Message

Citer : Posté le 11/06/2020 18:50 | #


Le remplissage du TLB qui permet de charger différentes parties de l'add-in ne peut être fait que par l'OS, donc c'est toujours un peu compliqué de savoir si ça va bien se passer. Je vous tiens au courant...

J'avais déjà fait quelque chose similaire lors de mon prototype de débogueur/traceur. Si tu as de quoi restaurer proprement l'environnement de Casio, ça ne devrait vraiment pas être complexe à mettre en place (en tout cas pour les SH4).

Là où il faut faire gaffe, c'est à l'endroit où tu invoques l'handler de Casio car il doit absolument être en RAM (pour éviter qu'il se fasse décharger). Autre point, ne fais pas mon erreur de vouloir rediriger l'exception (car j'avais des problèmes avec ce qu'affichait l'handler si la zone en question ne pouvais pas être mappée), appelle uniquement le syscall 0x0001.

Es-ce que tu ne serais pas gagnant en termes de perf' si tous les drivers de Gint étais relocalisés en RAM ?
Lephenixnoir En ligne Administrateur Points: 18144 Défis: 142 Message

Citer : Posté le 11/06/2020 19:13 | #


Ooh je ne savais pas qu'on avait le syscall 0x001 pour faire ça. Intéressant ! Ce sera sans doute plus fiable que le handler, comme tu dis. Est-ce que tu sais si ce syscall a des effets indésirables comme modifier la VBR ou ce genre de choses ? :o

L'affichage n'est pas trop un problème, je peux de toute façon vérifier que la page demandée est valide avant d'appeler le système.

Du reste oui, faut mettre plein de trucs en RAM. Est-ce que c'est mieux si les drivers y sont, je sais pas. D'un côté la RAM est plus rapide en théorie, de l'autre c'est pas de beaucoup et la RAM a déjà beaucoup plus de pression dans l'application à cause de la VRAM. Je sais pas à quel point un accès à la ROM peut être "parallèle" parce qu'il y a un bus d'adresse plus ou moins partagé entre le proco et tout le reste. Éventuellement on peut mettre du code critique dans la mémoire IL (sur SH4) mais ça je n'ai pas encore vraiment testé en termes de performance.
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 37, 38, 39, 40, 41, 42 Suivante

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
Pour coloriser votre code, cliquez ici.
Sinon cliquez sur le bouton ci-dessous.
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2020 | Il y a 56 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