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
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 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


Pages : Précédente1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 25Suivante
Dark stormHors ligneMembre d'honneurPoints: 10828 Défis: 176 Message

Citer : Posté le 08/07/2016 22:28 | #


À la rémanence de l'écran. Et ça, on y peut pas grand chose à part adapter les valeurs des timers du gris au mieux.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 08/07/2016 22:31 | #


Hmm... les bandes sont supposées être précisément ce qu'on ne voit pas sur cette vidéo. ^^'

Qu'on se mette bien d'accord : s'il y a quatre rectangles -- blanc, gris clair, gris foncé et noir -- c'est parce que c'est ce que j'ai mis dans la mémoire vidéo. C'est voulu. Ce que je veux maintenant c'est que ces quatre couleurs soient les plus stables et jolies possibles.

En l'occurrence ça clignote pas mal, mais il n'y a pas de « bandes parasites ». Ce sont des bandes qui remontent ou descendent tout l'écran en permanence et causent des variations de couleur là où elles passent : des dégradés moches, des inversions de couleur et même parfois la suppression pure et simple de l'illusion de gris, ne laissant que du noir et blanc. Ça c'est ce que j'ai réussi à éviter.
Dark stormHors ligneMembre d'honneurPoints: 10828 Défis: 176 Message

Citer : Posté le 08/07/2016 22:33 | #


Ce qu'il voulait dire, c'est que, sans doute à cause des 25 fps de ta caméra, on voit de légères bandes parasites à l'écran. Mais c'est pas du tout dérangeant par rapport à ce que j'avais testé de mon coté, via revolutionfx et l'addin de test.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 09/07/2016 08:46 | #


Oh, je vois. On voit quelques bandes sur le gris foncé au début de la vidéo.

Alors Ninestars, il faut que je précise. Le moteur de gris, c'est pas de la magie. Les bandes, il y en a toujours. La question c'est comment on s'arrange pour qu'on les voie pas trop. Il y a deux solutions :
- Elles sont si rapides que de loin (30 cm) l'effet est négligeable
- Elles ne bougent (quasiment) pas
J'ai des valeurs pour les deux solutions. Le premier cas, c'est celui que j'ai mis dans la vidéo. Le clignotement est assez fort, j'essaie d'y travailler mais c'est pas gagné d'avance. Le second, il est cool parce qu'il est hyper stable (aucun clignotement) et les couleurs sont pas trop mal. Son problème c'est qu'il y a une zone de 15-20 pixels au milieu dans laquelle la bande statique réside, où les couleurs sont plus ou moins inversées et un peu altérées. Ça bouge très lentement (genre d'un pixel par second) et ça reste plus ou moins dans la même zone, mais les pixels gris clair et gris foncé échangent carrément leurs positions.

Quand on dessine un tileset ou un objet qui ne possède pas de grandes zones de gris, ce dernier effet ne se voit pas trop, mais le rendu est pas très fidèle. Si on veut obtenir quelque chose de correct, il faut augmenter la vitesse des bandes jusqu'à ce qu'elle atteigne plus ou moins la fréquence « propre » de l'écran.

Le problème c'est qu'il y a deux effets à surveiller. J'ai compris comment calculer des valeurs pour lesquelles il n'y a pas de clignotement, mais pour les bandes c'est plus subtil. Ce dont j'ai peur c'est que si on fait accélérer les bandes jusqu'à ce qu'elles se confondent avec elles-mêmes à chaque passage (et ainsi disparaissent plus ou moins), alors cela crée nécessairement du clignotement. On ne peut pas se permettre de laisser des bandes, c'est très moche. Déjà sur cet exemple tu avais de dire que c'était moyen, et c'est clairement excellent par rapport à des réglages bourrins.

Pour qualifier un peu mieux, les meilleures suppressions de bandes sont dans la vidéos. Les réglages qui éliminent le mieux les clignotements les font disparaître totalement à 30 centimètres de distance.

Voilà, tout ça pour dire qu'on ne peut pas attendre des miracles et que vous vous casserez probablement les yeux si vous tentez de jouer à un jeu en gris à 5 centimètres.
Fife86Hors ligneMembrePoints: 830 Défis: 0 Message

Citer : Posté le 09/07/2016 09:03 | #


Est ce qu'on pourrais avoir le G1A pour tester chez nous le gris, si bien sur il marche sur SH4 ?
It's Show Time !!!
Mes Jeux :
- Street Fighter : Pour les accrocs du free-fight.
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".


< Le recoin du C-Engine >
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 09/07/2016 09:11 | # | Fichier joint


Il marche sur les deux machines, mais il faut le tester sur SH4. Les valeurs que j'ai ne fonctionnent pas bien sur SH3.

Tu peux te balader dans les menus. Pour le moteur de gris ([4]), les touches [F1] à [F3] configurent les valeurs que j'ai trouvées. La touche [F6] déplace le curseur. Les touches [←] et [→] modifient la valeur sélectionnée de 1, et [↑] et [↓] de 10.
Fife86Hors ligneMembrePoints: 830 Défis: 0 Message

Citer : Posté le 09/07/2016 09:26 | #


Merci
It's Show Time !!!
Mes Jeux :
- Street Fighter : Pour les accrocs du free-fight.
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".


< Le recoin du C-Engine >
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 12/07/2016 18:30 | # | Fichier joint


Bon, j'ai fais des tests avec des sprites... voilà à quoi ça ressemble.

En vrai le rendu est magnifique. Pour du gris léger, utilisé uniquement comme « décoration » et pas en grandes bandes comme la dernière fois c'est assez superbe

Dark stormHors ligneMembre d'honneurPoints: 10828 Défis: 176 Message

Citer : Posté le 12/07/2016 20:44 | #


Ah c'est top !
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
DrakHors ligneRédacteurPoints: 1925 Défis: 38 Message

Citer : Posté le 14/07/2016 10:15 | #


Joli travail, il y a de quoi être fier !
Eon the Dragon : version 1.2
Let's have a look!
Marre de ces RPGs qui t'imposent des classes, des compétences et des sorts ? Crée tes propres capacités sur Eon the Dragon ! Des monstres, des dragons et des combats aussi épiques que difficiles t'attendent !
Un RPG unique et immense t'attend ! Joue dès maintenant à Aventura, le Royaume Poudingue !
Vous aussi, soyez swag et rejoignez Planète Casio !
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 14/07/2016 21:01 | #


J'ai fait quelques tests sur la vitesse des bitmaps. C'est assez... énorme

J'ai compté le temps mis pour afficher des bitmaps par ML et gint. Les valeurs affichées sont dans une unité quelconque. « k » et « M » signifient milliers et millions, respectivement.

taille      position       clipping       ML        gint    rapport
-------------------------------------------------------------------
128x64        0, 0           oui        11.9 M     1.06 M    11.2
128x64      -64, -32         oui        3.25 M      335 k    9.69
128x64        1, 1           oui        15.2 M     1.65 M    9.16

gint est ici 10 fois plus rapide ! \o/
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 15/07/2016 12:40 | #


Oui en effet je parlais des raies qui se déplacent verticalement à l'écran. Et si tu montes en fréquence elles ne sont pas sencées disparaître ?
En tout cas cette effet n'est pas visible sur des sprites, c'est juste sur des grands rectangles ce que l'on n'affiche pas dans un jeu donc c'est parfait
Gint 10x plus rapide que ml... Moi qui pensait que ML était le summum bravo !
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 15/07/2016 12:46 | #


Je suis au minimum sur la vidéo, si je monte en fréquence c'est pire... bon, faudra éviter les gros rectangles quoi Pour les jeux, il est plus intéressant de voir le gris pour des petits effets de lumière, des textures ou des décorations. C'est plus proche du pixel art et c'est ce qui rend le mieux

Cela dit, j'ai encore trouvé des opti ce matin. Faudra que je teste pour quantifier mais il n'est pas impossible que la vitesse monte encore de 30-40%. Je commence à tomber à court d'idées par contre x)

Ajouté le 19/07/2016 à 14:16 :
Bon, j'ai un très joli problème de gestion de mémoire.

Pour faire simple, il y a une unité dans la machine appelée MMU (pour Memory Management Unit) dont le rôle est de traduire les adresses logiques (des pointeurs) en adresses physiques (vous vous doutez bien qu'il y a beau avoir 4 Gio d'adresses de pointeurs, il n'y a pas autant de mémoire physique).

Pour calculer les adresses physiques, cette unité utilise un tableau contenant les correspondances entre des blocs de mémoire logique et des blocs de mémoire physique. Ce tableau s'appelle le TLB (pour Translation Look-aside Buffer), et je viens de vous apprendre ce que sont 90% de vos System ERROR (élégamment nommées « TLB ERROR!! »). Ça se produit quand vous demandez d'aller lire la mémoire à une adresse qui n'est pas enregistrée dans le TLB.

C'est ce que je rencontre maintenant. Sur SH4 je les détecte moi-même, mais sur SH3 j'ai une System ERROR, ce qui signifie que l'erreur se produit avant même que je n'aie initialisé le gestionnaire d'exceptions et remplacé celui du système (c'est-à-dire dès le lancement du programme).

En général cette « erreur » est en fait un signalement : dans un système multi-processus, chaque correspondance de bloc entre la mémoire logique et la mémoire physique existe pour un seul processus. (De cette manière, si un autre processus tente d'accéder à la mémoire, l'accès lui est refusé : c'est la base de la sécurité.) Ainsi quand un processus A demande la RAM mais qu'il n'y en a plus, on sélectionne généralement des données peu utilisées dans la RAM (qui appartiennent à un processus B) et on les place sur le disque en attendant (dans un espace connu sous le nom de swap). On peut alors allouer la zone libérée au processus A. Si le processus B tente d'accéder à sa mémoire, le système de rend compte qu'il l'a donnée au processus A et réalise alors une commutation : il recharge les données du processus B dans la RAM.

Ici la solution est plus simple puisqu'il n'y a qu'un seul processus : il suffit de charger la correspondance entre mémoire logique et mémoire physique qui permettra d'accéder aux données que l'on cherche. Cependant, le système ne semble pas le faire (puisqu'il affiche les « TLB ERROR!! » au lieu de les résoudre) : il se permet a priori de tout charger d'un coup parce que le TLB est assez gros et de ne plus y toucher après en partant du principe que l'add-in n'a pas à tenter d'aller lire de la mémoire ailleurs.

Ça pourrait se passer tranquillement comme ça mais il n'empêche que j'ai de telles erreurs quand mes programmes deviennent gros et la limite est vite atteinte (encore plus vite sur SH3 que sur SH4). Il va donc falloir que je travaille au remplissage du TLB et c'est un peu long.

Voilà voilà, c'était surtout pour donner quelques nouvelles (vu que tout allait bien il y a quelques jours et depuis plus rien).

Ajouté le 11/08/2016 à 22:08 :
Tiens, je passe ici et je me rends compte que je n'ai pas donné de nouvelles depuis que je suis rentré de Bretagne.

J'ai trouvé une sorte de workaround qui oblige le système à charger ce que je veux dans le TLB avant d'initialiser gint pour ne plus avoir à y toucher après. Je pourrais modifier le TLB manuellement mais c'est une mauvaise idée. Cette méthode est garantie de fonctionner pour les add-ins de moins de 128 kio et garantie d'échouer pour ceux de plus de 384 kio. Entre les deux, c'est plus ou moins de la chance par rapport à ce que dit le système. J'ai pas encore essayé. Btw, ce que j'ai découvert coïncide avec la limite de 512 kio pour un add-in.

Je vais utiliser gint pour la vingtième édition du CPC, histoire d'en tester/démontrer les capacités en milieu réel. Je n'ai pas encore de garantie que ça fonctionnera sur toutes les machines mais j'ai bon espoir. À suivre !

Ajouté le 16/10/2016 à 10:01 :
Salut à tous ! Ça fait longtemps que j'ai pas posté sur ce topic. Histoire de répondre au message précédent, j'ai été content de constater quand dans l'immense majorité des cas gint a fait tourner sans défaut le programme sur des modèles variés ! À part quelques problèmes de backlight sur la G75, la portabilité a été au-delà de mes espérances. Le jeu en question, Arena, a finalement remporté le CPC

Le problème qui m'intéresse maintenant concerne plutôt l'API, et quelque chose que les dev's vont souvent utiliser. Il s'agit des événements.

Cake a proposé, qu'à la place d'utiliser getkey() et d'autres techniques spécifiques pour lire les événements du clavier, du port série (quand il sera implémenté) et tout ce qu'on pourrait ajouter, on centralise les informations dans un système d'événements comme celui de la SDL.

Cela pose quelques problèmes techniques, le premier étant celui du multi-getkey. Voici en quoi :
- En utilisation « normale » du clavier, on attend deux types d'événements : les pressions de touches et les relâchements de touche. Une seule touche par événement, tout arrive séquentiellement et tout se passe bien.
- En mode multi-getkey, on s'intéresse tout particulièrement aux pressions simultanées de touches et les relâchements importent peu. Les événements devraient pouvoir contenir plusieurs touches à la fois.

Ma question, pour vous du point de vue de l'utilisation de la lib', est : comment voulez-vous utiliser le getkey et le multi-getkey dans vos programmes ? (événements ou pas événements, un mode normal et un mode multi-getkey séparés ou confondus, deux fonctions getkey() et multigetkey() comme aujourd'hui, ou n'importe quoi d'autre)

Du point de vue technique, il y a d'autres problèmes à régler, notamment pour savoir ce qu'on l'on fait des événements accumulés lorsqu'on change de mode. La meilleure solution me semble quand même être de générer les événements clavier à la volée.
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 16/10/2016 10:15 | #


Pour ma part, j'aimerais une unique fonction qui reçoit en paramètre une liste de touche que l'on souhaite tester et qui modifie la valeur des variables en paramètre.
Genre :
int k_exe;
int k_left;
getkey(&k_exe, &k_left)
// k_exe = 0 si pas pressée et 1 sinon
if (k_exe == 1)
{
...
}

Si rien n'est pressé ça bloque
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 16/10/2016 10:16 | #


Comment veux-tu que la fonction comprenne de quelle touche tu parles dans ton exemple ?
Cakeisalie5Hors ligneMembre de CreativeCalcPoints: 1750 Défis: 10 Message

Citer : Posté le 16/10/2016 10:18 | #


Le multi-getkey, c'est caca. cf. le code crado que j'ai dû faire dans Tu Quoque, alors que les events permettent de faire ça proprement.

Le getkey, je suis pas chaud chaud pour, mais on peut imaginer que ça parcourt les events à venir pour uniquement considéré les évènements du type KeyDown.

Je te l'ai déjà dit sur la shout, mais comme môssieur des neufs étoiles exige ma participation ici : franchement, je sais pas pourquoi tu t'enquiquines autant avec le clavier. C'est pas compliqué : quand le timer arrive, tu check les touches qui ont changé d'état depuis le dernier gong, tu push les évènements correspondants (dans un ordre osef mais constant, si possible logique, genre de gauche à droite et de haut en bas), et voilà. (dans ma tête, les deux fonctionnent grâce à des timers quoi. celui du SH4 est juste moins préçis à cause de ce k,oiezngd de module KEYSC)

Le seul cas où tu as effectivement raison de t'enquiquiner selon moi (toujours, j'ai pas changé de corps entretemps), c'est "omg mais comment je sais si telle touche était appuyée à ce moment-là", et la solution évidente : stocker le buffer de clavier dans chaque event (puisque garder ce buffer côté utilisateur, bah, en cas de pipe overflow, il est fucked). Et voilà, t'as mon avis. >_>

Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 16/10/2016 10:19 | #


En effet je n'y avais pas pensé
getkey(&k_exe, &k_left, 31, 37)
Par exemple en utilisant les codes classiques ?

Merci Cake pour ta participations ici
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 16/10/2016 10:20 | #


Ceci n'est pas possible non plus, parce qu'il n'est pas possible de prédire le nombre d'arguments variables.
Au mieux, on pourrait faire :
getkey(&k_exe, 31, &k_left, 37, NULL);
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 16/10/2016 10:22 | #


Oui, pourquoi pas, je donne l'idée pour l'utilisation, comment ça fonctionne derrière c'est toi qui voit

Ajouté le 16/10/2016 à 10:25 :
Après ça fait pas hyper user friendly comme ça :/
Dark stormHors ligneMembre d'honneurPoints: 10828 Défis: 176 Message

Citer : Posté le 16/10/2016 10:30 | #


J'avoue que le coté évènementiel reste beaucoup plus propre. Après faut voir comment le mettre en pratique de manière user-friendly.

Déjà, je pense que personne n'utilisera gint pour faire autre chose que des jeux je pense. Donc pas d'entrée clavier "classique" à proprement parler. En suivant le raisonnement jusqu'au bout, on a aussi une prépondérance du multigetkey. Le getkey simple restant un cas particulier du multi.

Par contre, je propose pas de solution technique parce que j'ai aucune idée de comment faire. x)

Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
LephenixnoirEn ligneAdministrateurPoints: 15794 Défis: 136 Message

Citer : Posté le 16/10/2016 12:04 | #


Je pense que j'ai trouvé ce que je vais faire. Le dev' va demander des événements clavier, sous différentes formes et le clavier va lui renvoyer les événements qu'il a demandé. Chaque forme d'événements aura une fonction indépendante.

Certaines formes ne donneront que les touches pressées, d'autres donneront les touches unes par unes et d'autres simultanément. Certaines formes pourront utiliser les modificateurs SHIFT et ALPHA, d'autres ne pourront pas. Au final, ce seront les mêmes compte-rendus d'événements claviers, mais pas présentés pareil.

Ma priorité reste d'avoir du code simple pour chaque utilisateur. Darks, je compte bien passer WebCalc sous gint quand le projet sera assez stable. Il faut que le code du clavier soit aussi simple que possible, et la souplesse de ce système me convient plus que pour tout autre système auquel j'ai pensé jusqu'à maintenant. On pourra également intégrer la proposition de Ninestars.

Ça va être difficile à implémenter mais ce n'est pas mon problème, à la limite. Au final, on aboutirait sur différentes interfaces comme :
- getkey()
- multigetkey()
- getevent()
- multigetevent()
Ne criez pas à l'arnaque.
Pages : Précédente1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 25Suivante

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