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 Hors ligne Administrateur Points: 18201 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 ··· 39, 40, 41, 42, 43 Suivante
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 20/06/2020 22:37 | #


Aha RIP. Ça m'est arrivé une fois aussi, j'ai tout recompilé dans le doute. Sinon tu fous des liens symboliques pour tout le monde non ?

Ajouté le 20/06/2020 à 23:06 :
J'ai poussé sur la branche dev une modification de la fonction timer_setup() qui permet de configurer les timers. Je sais que c'est un point compliqué pour pas mal de gens, donc j'ai essayer de simplifier ça sans casser le code qui veut exploiter toute la puissance du système.

La nouvelle fonction a un prototype largement plus simple avec seulement trois arguments obligatoires :
• Le timer que vous voulez utiliser (vous pouvez aussi laisser gint en choisir un)
• Le délai en micro-secondes
• La fonction à appeler une fois le délai écoulé

Modification 1 : plus besoin de gérer les numéros de timers. En général vous vous en foutez pas mal de savoir qui est un TMU et qui est un ETMU, disponible ou pas, et si la précision est de 0.3 ms ou 0.3 µs. Et en général perso j'ai pas envie de traquer quel timer j'ai utilisé à quel endroit. Et donc on peut simplifier les deux situations en mettant TIMER_ANY en premier argument. gint se charge de trouver un timer disponible qui est capable d'attendre le délai que vous demandez.

/* Exécuter f() dans 25 ms */
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

Évidemment il faut quand même vérifier qu'un timer libre existe bel et bien; timer_setup() renvoie -1 si aucun timer n'est disponible pour répondre à votre demande.

Modification 2 : le délai directement en micro-secondes. Mais si vous voulez utiliser explicitement un timer par son ID, le délai est traité comme une valeur de TCOR, comme avant (utile pour libprof et le moteur de gris, notamment). Mais bon les power users peuvent lire le header, je détaille pas ici.

Modification 3 : plus de type bizarre sur les fonctions de callback . Grâce à de la magie noire de GCC, timer_setup() accepte différents types de callbacks, notamment int f(void) (aucun argument). Dans ce cas vous n'êtes pas obligés de passer un argument à timer_setup(). Le callback peut avoir au plus un argument qui doit forcément être de 4 octets (en gros : un entier ou un pointeur).

/* Exécuter f() dans 25 ms */
int f(void) { ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

/* Exécuter g(5) dans 25 ms */
int  g(int x) { ... x ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, g, 5);
if(timer >= 0) timer_start(timer);

Comme avant le callback doit renvoyer un entier indiquant au timer s'il doit continuer à tourner ou s'arrêter. Mais au lieu de 0 et 1, ils s'appellent maintenant TIMER_CONTINUE et TIMER_STOP, ce qui est quand même plus agréable.

Pour adapter votre code. La plupart des appels à timer_setup() jusque-là avaient cette forme :

timer_setup(<id>, timer_delay(<id>, <delay>), timer_default [ou 0], <callback>, <arg>);

La façon safe de transposer ça dans la nouvelle API sans risquer de problème est ceci :

timer_setup(<id>, timer_delay(<id>, <delay>, TIMER_Pphi_4), <callback>, <arg>);

Mais ça c'est que si vous voulez utiliser explicitement le timer <id>. Si au fond n'importe quel timer vous convient, vous pouvez utiliser TIMER_ANY et dans de cas gint calculer timer_delay() pour vous. Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>, <arg>);

Enfin si votre callback ne prend au fond pas d'argument (avant vous étiez obligés d'en avoir un de type volatile void *), vous pouvez le retirer (votre callback et alors de type int callback(void)) et ne plus le passer à timer_setup(). Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>);


Voilà, j'espère que ça vous simplifiera les choses pour aborder tranquillement les timers sans maux de tête. J'ai fait de mon mieux pour garder l'API proche de l'ancienne version pour que les changements soient faciles pour vous.

Ajouté le 29/06/2020 à 21:32 :
Je continue à bosser sur la prochaine release. Actuellement, j'essaie de rendre gint compatible avec l'émulateur officiel Graph 90+E. La plupart des choses semblent fonctionner, mais l'affichage à l'écran non (ce qui rend difficile le test dans la plupart des cas !).

J'ai déjà déterminé que la méthode naïve pour afficher des données (envoyer chaque pixel à l'écran par l'action du CPU) fonctionne, seule la méthode DMA semble échouer. Je vais voir ce que je peux trouver là-dessus, au pire cas je peux toujours utiliser la méthode naïve car les problèmes de performance ne sont pas aussi intéressants sur l'émulateur que sur la calculatrice.

S'il s'est passé un bon moment depuis la dernière update (9 jours) c'est qu'en décortiquant l'émulateur j'ai trouvé plein d'infos intéressants sur le SH7305 et j'ai pris un moment pour évaluer les conséquences sur le reverse-engineering du matériel avec Yatis.

Ajouté le 02/07/2020 à 11:21 :
J'ai progressé. En fait je crois que sur la calculatrice la RAM est à 8c000000 (ou ac000000) tandis que sur l'émulateur elle est à 88000000 (ou 8c000000). La preuve c'est que je me sers de cette méthode pour différencier Prizm et Graph 90+E et l'émulateur est détecté comme une Prizm ! De plus, les problèmes d'affichage n'étaient pas liés au DMA mais au fait que j'utilisais une zone de RAM qui n'existait pas (puisque pas au bon endroit dans la RAM).

Il est donc possible que l'émulateur est la Graph 90+E n'utilisent pas tout à fait le même OS. Ça mérite d'être étudié.

Ajouté le 02/07/2020 à 16:08 :
Alright, donc grâce aux mécanismes de compatibilité Prizm de gint, la transition vers l'émulateur s'est faite sans problème. Le fx-CG Manager de Casio est désormais officiellement une platforme supportée par gint

Je pense que c'est le bon moment pour tester sur Prizm aussi.

--

Sentaro21, a couple months ago you mentioned that you might be able to test the project on fx-CG 20. If you can still do it, please download the test application gintctl.g3a (you will need to rename it).

The application has many tests but I'm interested in the following information in the GINT tab:
• In "Hardware", the "MPU/CPU" page should show "Calculator model: Prizm fx-CG 20"
• In "Memory dump", you should be able to press F3 then F6 to dump some of the RS RAM to a file called RS00.bin without a crash
• In "Switch to OS", you shoud be able to press F1 (SWITCH) repeatedly without a crash, and you should also be able to press F3 (MENU) to switch between the main menu and the add-in.
• In "TLB management", pressing F5 (MISS) and F6 (TIMER) should map new pages (more squares should be green).
• In "Timers", you should see TMU2 and ETMU5 running, and pressing F1 (SLEEP) sould make TMU0 run for about a second
Finally, in the MEMORY tab of the main menu, you should be able to press F3 (ROM) then Up and have a red "TLB error" on screen.

Because it works on fx-CG 50 and in the fx-CG Manager which behaves like an fx-CG 20, I am confident this will work.
Kirafi Hors ligne Membre Points: 2145 Défis: 10 Message

Citer : Posté le 04/07/2020 10:28 | #


Hello, une date de realease en vu pour une version 2 stable ? De ce que j'ai compris elle est quasiment prête t'es en train de faire quelques petits correctifs ?
iPod
Pour des parties rapides
Jusqu'où pourras-tu aller dans ce jeu "partie rapide" qu'est Dextris (élu Jeu Du Mois)
Pourras-tu survivre plus de 20 secondes dans ce fameux tunnel appelé Graviton
Rebondis entre les murs en évitant les piques dans SpikeBird
Pourras-tu éviter de te faire écraser dans FallBlocs (élu Jeu Du Mois)
Autres
Franchement ils valent le coups
Deviens l'amiral de la marine dans SeaRush (jeu concours) (élu Jeu Du Mois)
La version 2048 tactile amélioré au plus haut point : 2048 Delux !
Pars à la recherche des morceaux d'étoile dans Lumyce (élu Jeu Du Mois)
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 04/07/2020 11:02 | #


Yo ! Donc en effet je suis en bêta là, la plus récente étant la 2.0.2-beta.

Voilà la TODO list des features avant la fameuse 2.1 que je tease depuis un moment :
• Faire les fonctions de mémoire optimisées : memcpy, memcmp, memset, et pour memmove je reste naïf (je suis là tout de suite dessus) [4]
• Supporter la Prizm fx-CG 20, normalement c'est bon j'attends juste un test (non bloquant pour la 2.1)
• Double-buffer les paramètres du moteur de gris (en gros : activation frame-perfect du moteur) [2-3]
• Supporter les polices Unicode dans topti (pour uf5x7 et virer les anciens charsets) [2-3]
• Gérer le spread spectrum sur Graph 90+E, les timers sont pas tout à fait précis actuellement [1]
• Ajouter une valeur de retour de main() qui permet de revenir au menu au lieu de quitter l'add-in et donc de revenir [1]

Voici les choses que je dois casser :
• Supprimer image_t qui a été renommé bopti_image_t par clarté
• Supprimer la branche compat, maintenant tout le monde doit utiliser master ou dev
• Unifier les fonctions g*() avec les d*() ; vu que le moteur de gris est double-buffer, plus besoin de séparer [2]

Et voici des choses qui iront dans les releases suivantes :
• Système de fichiers propre
• Overclock
• Musique avec la méthode de TSWilliamson
• Communication série et USB
• Jouer avec le DSP, si ça peut aider

J'ai mis entre crochets une estimation du nombre d'heures pour faire marcher les points principaux. Le temps que j'arrive à passer sur gint est assez instable cette semaine mais j'espère pousser la release à la fin de la semaine prochaine ou au début de la semaine suivante, donc autour du 12-14 Juillet.
Kirafi Hors ligne Membre Points: 2145 Défis: 10 Message

Citer : Posté le 04/07/2020 16:04 | #


C'est quoi le truc du double buffer ? ça va améliorer le moteur de gris ?
Le retour au menu c'est une grande première dans les Add-In haha !

C'est cool pour la branche master ça fait plus propre .

Les release suivante sont dans l'ordre ou pas là ? Car je pense que la communication est assez importante comparé aux autres.

Okay bon, tkt si ça prend un mois c'est pas grave c'est déjà ouf ce que tu produis !
iPod
Pour des parties rapides
Jusqu'où pourras-tu aller dans ce jeu "partie rapide" qu'est Dextris (élu Jeu Du Mois)
Pourras-tu survivre plus de 20 secondes dans ce fameux tunnel appelé Graviton
Rebondis entre les murs en évitant les piques dans SpikeBird
Pourras-tu éviter de te faire écraser dans FallBlocs (élu Jeu Du Mois)
Autres
Franchement ils valent le coups
Deviens l'amiral de la marine dans SeaRush (jeu concours) (élu Jeu Du Mois)
La version 2048 tactile amélioré au plus haut point : 2048 Delux !
Pars à la recherche des morceaux d'étoile dans Lumyce (élu Jeu Du Mois)
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 04/07/2020 22:01 | #


Kirafi a écrit :
C'est quoi le truc du double buffer ? ça va améliorer le moteur de gris ?

En gros quand tu fais gray_start() ou gray_stop(), au lieu d'activer ou de désactiver le moteur de gris tout de suite, ça ne le modifie qu'au prochain dupdate(). Comme ça tu as le temps de pousser ton premier frame en gris (ou ton premier frame mono après l'arrêt du moteur de gris) sans risquer que des VRAMs impropres s'affichent brièvement.

Les release suivante sont dans l'ordre ou pas là ? Car je pense que la communication est assez importante comparé aux autres.

Ouh là non c'est pas encore un plan tout ça ! Une partie de ces choses dépend de résultats de reverse-engineering qu'on est encore en train d'établi donc c'est vraiment dur de donner une estimation.

Okay bon, tkt si ça prend un mois c'est pas grave c'est déjà ouf ce que tu produis !

Merci ! Ça devrait pas prendre un mois quand même. Je me suis débarrassé des fonctions de mémoire tout à l'heure.

Ajouté le 06/07/2020 à 18:24 :
J'ai trouvé des problèmes bizarres sur le retour au menu, en particulier sur SH3, donc j'enquête. Je reprendrai les ajustements sur le moteur de gris quand j'aurai trouvé.
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 07/07/2020 12:58 | #


Hi, are there any plans to implement some standard math library functions? I would use the newlib port but I can't find any working repos for it (I did manage to implement the cosine function I needed in my code).
Dark storm En ligne Membre d'honneur Points: 11108 Défis: 176 Message

Citer : Posté le 07/07/2020 20:45 | #


Maybe you can look at the Memallox' port of Newlib : https://gitea.planet-casio.com/PlaneteCasio/libc

I do not know if it includes math functions, but it's definitely the more complete project of a libc on Casio calcs
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 08/07/2020 02:56 | # | Fichier joint


That refuses to build for some reason, the compiler finds errors in /libc/newlib/libc/include/ieeefp.h and stops. I don't know enough to try messing around with the header and fix them, I've attached a text file containing the output.

EDIT: Adding a
#define _LDBL_EQ_DBL
to the header seemed to fix it, everything compiled correctly. The SuperH manual says long doubles and doubles are the same size, so hopefully there shouldn't be any problems...

EDIT 2: Hooray! After adding -lm to the compiler flags for the addin everything seems to be working perfectly! Thanks for the link to the repo, all the ones I could find were dead.
Dark storm En ligne Membre d'honneur Points: 11108 Défis: 176 Message

Citer : Posté le 08/07/2020 09:34 | #


You're welcome

If you think your patch is clean enough to be integrated to the code repository, we'll pleased to create you an account on the Gitea, so you can post a merge request. Maybe you can add some notes/hints too.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 08/07/2020 14:32 | #


Unfortunately, unless someone can reproduce it, I can't be sure if it was a missing define somewhere or if I messed up earlier building the bootstrap GCC.
I do think the newlib/gcc tutorials should say that '-lm' needs to be added to the compiler options (or in the fxSDK project config) when compiling an addin for the math library to be linked, I was worried for a bit that I didn't build newlib/gcc properly
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 08/07/2020 16:47 | #


Interesting, I didn't have this problem when building the library. I did experience some crashes with core memory functions like memcpy() using this port (that did not appear with naive implementations), so if you encounter trouble know that newlib might (?) be in fault.

My stance on the standard library is not very clear yet. I wanted to use this newlib port at some point but Memallox has unfortunately not developed it for a while. gint currently provides a couple optimized memory and string functions but I haven't yet gone all the way and implemented the whole set.

As for the math library, I think we can at least port an independent libm as the Prizm SDK does (although it ships libm.a directly without explaining how to build it so it's not that useful). Just for completeness, you can find that file here (I don't know whether there is an official PrizmSDK repository so I pointed to TSWilliamson's personal version - the binary libraries should be the same).

Hope this helps clarify the situation. Also, thanks for your interest in this project

Ajouté le 08/07/2020 à 17:29 :
Lephenixnoir a écrit :
J'ai trouvé des problèmes bizarres sur le retour au menu, en particulier sur SH3, donc j'enquête. Je reprendrai les ajustements sur le moteur de gris quand j'aurai trouvé.

J'ai continué et j'ai trouvé... pas mal de problèmes sur SH3, wow. Ils sont apparus avec le changement de l'API timer mais ça n'a pas vraiment de raison d'être lié. Visiblement la zone dans laquelle j'installe la VBR et la mémoire mappée de gint est vraiment pas fiable. Il faut que je voie au plus vite si je peux m'en débarrasser, même si c'est pas gagné. En gros j'ai besoin d'une zone non virtualisée dans P1 ou P2 pour avoir la VBR et une poignée de fonctions auxiliaires. Une fois les trivialités éliminées, en gros il me faut une zone de RAM d'environ 8k. Pour l'instant j'étudie mes options, je vous tient au courant.

Ajouté le 10/07/2020 à 11:56 :
Okay donc petite explication de ce qui se passe ici. Il y a grosso modo 3 types de mémoire sur la calto : la ROM, la RAM, et la mémoire on-chip. Quand on lance un add-in, on a le code dans la ROM et les données dans la RAM. Pour accéder à la ROM et à la RAM, normalement on utilise des adresses "absolues" qui accèdent exactement à l'octet qu'on demande.

Cela pose deux problèmes pour les add-ins. D'une part le code est dans le fichier g1a/g3a, qui est fragmenté dans la ROM, donc il n'est pas continu (l'instruction qui suit l'instruction actuelle peut être à l'autre bout de la ROM). D'autre part la zone de RAM que l'OS nous donne n'est pas au même endroit ni de la même taille d'une version de l'OS à l'autre. Tout cela fait qu'il est quasi-impossible de savoir où le code et les données sont.

Pour pallier à ce problème (et d'autres !), un outil matériel appelé le MMU a été inventé. Le MMU présente des adresses "virtuelles" à l'add-in et les traduit en adresses "absolues" de façon transparente. Ainsi, le système peut configurer le MMU pour me présenter le code de mon add-in dans des adresse virtuelles consécutives tout en les redirigeant individuellement vers les fragments du fichier g1a/g3a qui peuvent être éparpillés dans la ROM. De même, il peut présenter une adresse virtuelle fixe pour la RAM même si l'adresse absolue change. En pratique, on n'utilise quasiment que ces adresses virtuelles.

Mais dans gint, j'ai une poignée de code et de données que je dois absolument désigner par une adresse absolue dans la RAM. Sur Graph 90+E, j'accède au MMU pour connaître l'adresse absolue accordée à l'add-in et je m'installe là. Sur Graph mono, historiquement je me plaçais à une addresse fixe qui semblait inutilisée.

Donc ce que j'ai découvert récemment à travers le retour au menu c'est que la zone est effectivement utilisée et que revenir au menu provoque une écriture dedans. Ça veut dire que chaque fois qu'on revient au menu, des variables et tableaux de gint se font modifier de façon aléatoire. Comme vous pouvez vous en douter, ce n'est pas une situation acceptable.

Donc ce que j'ai commencé à faire c'est préparer le terrain pour déplacer mes données sensible au début de la zone de RAM accordée par l'OS, comme je le fais sur Graph 90+E. Mais cela pose quelques difficultés. Sur SH3, il n'y a que 8k de RAM disponible, et mes données sensibles prennent de base.... 8k aussi. Donc j'ai commencé à agencer tout ça de façon à le faire tenir dans moins, même si c'est pas tout à fait gagné encore. J'espère tout fait tenir dans 3k-4k.

Actuellement je suis en train de debugger le déplacement ; j'espère faire marcher tout ça ce soir. Ça veut dire que je dois attendre un peu pour faire les autres modifications (celles du moteur de gris), mais je vais faire au plus vite.

Ajouté le 10/07/2020 à 17:08 :
Voilà, j'ai fait ces modifications. Tout confondu j'arrive à faire tenir les données dans environ 4k, donc il reste 4k de variables globales sur SH3 (j'envisage de gratter 1k en déplaçant la VRAM). Notez que ces problèmes de taille c'est vraiment spécifique à la SH3, il reste aisément 28k sur SH4 et plus de 500k sur Graph 90. J'en ai profité pour réduire un peu l'empreinte mémoire de gint et gintctl de façon générale. Au total gintctl utilise que 500 octets sur les 4k qui restent donc vous voyez que si on fait un peu attention même une grosse appli a pas besoin de beaucoup de mémoire.

En fin de compte ça m'a pris un moment mais ça a bien nettoyé les facteurs d'incertitudes/instabilité dans gint. Cela explique et résoud en même temps les quelques bugs de retour au menu sur Graph mono que j'avais laissés il y a quelques mois. Il me reste quelques observations étranges sur SH3, mais pas reproductibles donc pour l'instant je ne peux rien y faire. (Assurer la compatibilité sur plusieurs plateformes est plus dur que ça peut en avoir l'air, toutes ces calculatrices ont quand même des sales différences qui rendent le boulot compliqué. xD)

Donc je reprends la liste des modifs que j'ai indiquée à Kirafi et j'espère ne pas croiser d'autre problème majeure du type avant la prochaine release.

Nouvelle bêta : gint 2.0.3-beta

Nouvelles fonctionnalités :
• Ajouté une fonction drect_border() pour les rectangles avec des bordures de tailles et couleurs variables
• Ajouté deux fonctions dtext_opt() et dprint_opt() permettant de contrôler l'alignement du texte
• Compatibilité Prizm fx-CG 20 (encore à tester sur une vraie machine, que je n'ai pas)
• Compatibilité avec l'émulateur fx-CG Manager
• Ajouté des valeurs par défaut correctes pour le moteur de gris sur les Graph mono autres que la Graph 35+E II
• Fonctions memcpy(), memset(), memcmp() et memmove() optimisées à fond à la fois sur SH3 et SH4

Changements :
dtext() et dprint() ne spécifient plus la couleur de fond, c'est désormais géré par dtext_opt() et dprint_opt()
• Supprimé le boot log, un vieux mécanisme de debuggage
• Retiré l'utilisation d'une région "rram" héritée des Graph mono sur Graph 90
• Ultime modification de l'API timer pour vous simplifier la vie sans casser le code existant. Instructions de migration ici.
• Modifié la structure de la VBR sur SH3 pour économiser de la mémoire.
• En conséquence du point précédent, supprimé la région "rram" pour utiliser une partie des 8k de mémoire utilisateur à la place

Corrections de bug : plein, mais aucun qui m'a été rapporté. Principalement :
• Instabilités sur SH3 lorsque le retour au menu est utilisé.

Ajouté le 11/07/2020 à 15:50 :
Super nouvelle, Sentaro21 a pu tester l'application de test, gintctl, sur sa Prizm. Et ça marche sans problème ! gint supporte donc à divers degrés de perfectionnement toutes les calculatrices Casio hors Classpad sorties depuis 10 ou 15 ans
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 13/07/2020 17:23 | # | Fichier joint


J'ai poussé sur dev une modification importante de l'API du moteur de gris. Ce changement simplifie grandement la gestion du gris pour vous et pour moi.

Modification 1 : alignment de dgray() avec dupdate()

Le moteur de gris est maintenant géré par une fonction dgray() qui se met d'accord avec le module de rendu pour n'activer et désactiver l'illusion de gris que lorsque vous envoyez la VRAM avec dupdate(). De cette façon, aucun frame ne peut apparaître à l'écran, ce qui était possible avant dans l'intervalle entre l'appel à gray_start() (qui démarre l'illusion) et gupdate() (qui fournit le premier frame en gris).

L'activation du moteur de gris se passe donc en deux étapes : on allume le moteur avec dgray(), ce qui active le rendu en gris (voyez la Modification 2) mais sans activer l'illusion de gris, et ensuite on appelle dupdate() pour envoyer notre premier frame gris à l'écran et activer en même temps l'illusion. De même à l'extinction, on arrête le moteur avec dgray(), ce qui revient au rendu mono mais sans désactiver l'illusion de gris, et ensuite on appelle dupdate() pour envoyer notre premier frame mono à l'écran et désactiver en même temps l'illusion.

Modification 2 : remplacement des fonctions de rendu g*() par d*()

Les fonctions de rendu du moteur de gris ont toujours été très redondantes par rapport aux fonctions de rendu mono. Désormais, dgray() remplace les fonctions d*() pour utiliser les versions appropriées du moteur de gris. Pour certaines raison de nommage, cela réduit la quantité de code à dupliquer entre le rendu mono et le rendu gris. Vous avez peut-être remarqué que quand j'ai ajoué dtext_opt() et drect_border() j'ai oublié d'ajouter leurs équivalents pour le moteur de gris ; grâce à la redondance supprimée ça ne se produira plus.

La façon correcte de dessiner dans le moteur de gris est désormais d'utiliser d*() comme avant. On peut donc écrire dtext(x, y, C_LIGHT, str) lorsque le rendu gris est activé.

Modification 3 : ajout d'une fonctionnalité de sauvegarde de l'état

Une fonction qui utilise le moteur de gris ne peut souvent pas juste l'allumer, l'utiliser et l'éteindre. Parce que si la fonction appelante l'utilisait déjà, alors l'éteindre va casser ou gêner son affichage. Et si par exemple ma carte du monde peut s'ouvrir à la fois depuis la map (qui est en niveau de gris) et le menu (qui est en noir et blanc), il n'y a pas de comportement fixe qui convienne.

Pour cette raison, la nouvelle API fournit DGRAY_PUSH_ON et DGRAY_PUSH_OFF qui sauvegardent l'état actuel du moteur avant de l'allumer ou l'éteindre. On les utilise au début d'une fonction en gris et d'une fonction mono, respectivement. À la fin de ces fonctions, on utilise DGRAY_POP qui restaurent l'état sauvegardé au début. De cette façon, dans ma carte du monde qui commence par DGRAY_PUSH_ON, l'appel à DGRAY_POP conservera le moteur allumé si je suis venu par la map et l'éteindra si je suis venu par le menu !

Pour adapter votre code. Il n'y a quasiment que du remplacement brut à faire pour adapter votre code à cette nouvelle API.

• Remplacez gray_start() par dgray(DGRAY_ON) et gray_stop() par dgray(DGRAY_OFF).
• Remplacez les fonctions de rendu comme gclear par leurs équivalents usuels comme dclear.

Les fonctions moins courantes du moteur de gris ont aussi été groupées sous le préfixe dgray() :

gray_delays()dgray_setdelays()
gray_config()dgray_getdelays() (l'état est donné par dgray_enabled())
gvram()dgray_getvram()

Attention, les modifications de dtext() et dprint() qui n'avaient pas été propagées à gtext() et gprint() (un oubli de ma part) s'appliquent maintenant. Pour rappel :

gtext(x, y, str, fg, bg)dtext(x, y, fg, str)
gprint(x, y, fg, bg, format, ...)dprint(x, y, fg, format, ...)

Pour choisir un fond non transparent, utilisez dtext_opt() et dprint_opt().

Le seul changement auquel vous devez faire attention est l'ordre d'activation et dessin du premier frame. Vous devez toujours activer le gris dans cet ordre-là :

/* D'abord on active le rendu en gris pour que d*() soit en gris */
dgray(DGRAY_ON);
/* On dessine le premier frame en gris */
dclear(C_LIGHT);
dline(0, 0, 10, 10, C_DARK);
/* On envoie le frame, ce qui active l'illusion de gris */
dupdate();

Si vous avez utilisé un autre ordre (notamment dessiné le premier frame avant d'activer le moteur de gris), vous devrez échanger les appels pour obtenir l'ordre ci-dessus.

Vous pouvez aussi utiliser les modes DGRAY_PUSH_ON, DGRAY_PUSH_OFF et DGRAY_POP si ça s'applique à votre cas d'usage, mais vous n'en avez pas besoin pour continuer à travailler avec la nouvelle API.

(Je mets un fichier joint stupide pour forcer la création d'un nouveau message, j'aurai besoin du permalink plus tard.)
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 14/07/2020 15:24 | # | Fichier joint


Et voici une fonctionnalité que j'attendais depuis un bon moment : les polices Unicode !

Pour adapter vos programmes. Vous devez mettre à jour et réinstaller le fxSDK, ensuite mettre à jour et réinstaller gint, puis recompiler intégralement vos programmes avec make -B.

Voilà par exemple les chaînes de caractères telles que je les ai tapées dans gintctl et le résultat à l'écran avec la police uf5x7.

char const *strings[] = {
    "Text rendering",
    "Eurêka! UTF-8!",
    "∀Δ, ∀f : P(Δ)→Δ,",
    "∃(A,B)⊆Δ, f(A)=f(B)",
    "2 = Λα.λf.λn.f (f n)",
    NULL,
};


C'est aussi facile que ça et ça fait un bien fout de pouvoir mettre les accents où il faut sans se poser de questions !

Donc voilà comment ça marche. Les polices Unicode peuvent contenir n'importe quel ensemble de caractères donc une seule image ne suffit pas ; à la place on met une image par bloc et on nomme le fichier avec le numéro du premier caractère représenté (exemple ici). Mais dans l'esprit c'est pareil que les autres, on met juste un dossier complet dans assets-{fx,cg}/fonts au lieu d'une seule image.

Dans project.cfg on indique charset:unicode pour la police en question, et ensuite c'est comme d'habitude ! On récupère la police avec extern font_t font_<name>, dfont() pour l'activer, et c'est parti !
Dark storm En ligne Membre d'honneur Points: 11108 Défis: 176 Message

Citer : Posté le 14/07/2020 17:48 | #


Propre. J'attends plus que la release sur master pour mettre à jour les paquets
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 15/07/2020 08:34 | #


This has probably been talked about before, but having flags in dsubimage to mirror the sprite horizontally or vertically when drawn would be great for stuff like animations. I don't know how bopti_image_t stores the sprite data though (is it packed like the VRAM is?), or if it's worth adding flags and code for something that wouldn't be used too much.
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 15/07/2020 08:45 | #


You guessed everything correctly, it's been mentioned but it's not easily possible specifically because the data is packed for maximum rendering speed.

I could hack it to oblivion to make it work, but then it won't handle 90-degree rotations (genuinely impossible with this format), upscaling, etc.

A while ago I implemented an external library called libimg (topic here, repository here) to do exactly this. It uses a simple bitmap format (1 byte per pixel on fx-9860G as opposed to 3 bits in a gray transparent sprite in bopti) and supports horizontal flipping and much more.

It's integrated into fxconv so the procedure is not too different from bopti.
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 15/07/2020 08:59 | #


Probably a bit easier just to make separate mirrored spritesheets for my use case , though libimg does seem like it might come in handy at some point.
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 15/07/2020 09:02 | #


Yes it's clearly easier, I personally prefer to start this way because when detailing the sprites, versions that were initially symmetrical often become completely different so the flipping method isn't useful (unless you have storage problems in your g1a file).
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 15/07/2020 09:31 | #


Also, I've had a weird issue after updating gint a couple of days ago - whenever I create a new sprite, the transparent pixels in the PNG are drawn as black in the addin. Existing sprites don't have this problem, though, and since it's fxconv that makes the sprites I'm a bit confused.

EDIT: It might actually be because the images could have more than 4 colours, I'm using some sprites taken from the actual game and might have missed a few pixels.

EDIT 2: Nope, definitely something fishy, I made a sprite with 4 colours and transparency and the transparent bit's getting drawn as black.
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 15/07/2020 10:05 | #


I have such a test image in gintctl and it's displaying correctly even now. Can you please check the fxconv command-line for this image to see if a profile was specified (maybe in project.cfg)?
Kbd2 Hors ligne Membre Points: 90 Défis: 0 Message

Citer : Posté le 15/07/2020 10:09 | # | Fichier joint


The command-line looks normal - "fxconv --bopti-image assets-fx/img/Untitled.png -o build-fx/assets/img/Untitled.png.o --fx --toolchain=sh-elf name:img_Untitled" (Untitled.png is the test image)

Ajouté le 15/07/2020 à 10:42 :
Looks like it only happens when you have too many transparent pixels?

Ajouté le 15/07/2020 à 11:25 :
I've been experimenting with it and it's really inconsistent. A fully transparent image will be drawn fine, but put a few black pixels in and the whole thing turns black. Some other sprites have no problems with transparency. This is on the latest commit of the dev branch. dtext and dprint also appears to be broken, when I build the default addin it hangs the calc
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 39, 40, 41, 42, 43 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