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: 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 ··· 32, 33, 34, 35, 36, 37, 38 ··· 40, 41, 42, 43 Suivante
Redcmd Hors ligne Membre Points: 273 Défis: 5 Message

Citer : Posté le 27/01/2020 08:54 | #


fx-9750GII
02.04.0201

RedCMD#4299 - Discord
Mandelbrot SNKEmini Minesweeper Sudoku
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 10/02/2020 14:59 | #


Salut !
Je suis en train de coder un petit jeu utilisant gint, et je voulais demander s'il y a moyen d'upscaler les images ?
C'est à dire faire en sorte d'afficher les images en taille multipliée par un facteur entier (16x16 -> 32x32 par exemple).
Merci d'avance
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 10/02/2020 15:40 | #


Hmm... non, malheureusement il n'y a pas trop de moyens de prétraiter les images. La raison est simple : les images sont stockées dans un format très orienté dessin, le but est que ça dessine le plus vite possible, c'est tout. (Et ça le fait bien !)

Par contre ce format ne permet pas trop de faire des joyeusetés...

C'est pas du tout la première fois qu'on me pose la question donc je vais réfléchir à une alternative. Ce qui est sûr, c'est qu'il y a des opérations qui sont structurellement coûteuses comme tourner de 90°, faire un miroir horizontal, ou redimensionner. Ça peut pas aller aussi vite, et donc je pense qu'il faut un format différent (je tiens à garder mon format optimisé parce que souvent les images sont dessinées sans transformation et là il faut que ça aille vite).

Pour l'instant je peux te garantir que tu auras les meilleurs perfs en utilisant une version déjà upscalée dans ton dossiers d'assets... mais je reconnais que c'est pas forcément idéal, ça prend de la place après tout.
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 10/02/2020 15:46 | #


OK pas de problème pour moi, je vais partir sur de l'upscalé
Dans mon programme actuel il y a un sprite de 12x12 dessiné toutes les frames, je ne pense pas que l'upscale sur ce genre de dessins aurait été impactant (l'écran n'est dessiné qu'une fois au début de l'exécution).
Si j'ai bien compris (je ne suis vraiment pas sûr), il y a moyen de faire des rotations ? Comment ?
Ça m'intéresserait, j'ai un sprite en quadruple (un pour chaque orientation multiple de 90).
(Tout marche niquel sinon, j'adore )
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 10/02/2020 18:13 | #


Bon, j'ai décidé de comment j'allais attaquer ce problème.

Je vais créer une nouvelle option à fxconv pour utiliser le format d'image avec transformations. Ce sera un truc du genre transform:true à mettre sur la ligne de l'image. L'image sera alors convertie dans un format "naïf". Dans le programme rien ne change, dimage() continue de dessiner, mais c'est plus lent qu'avant. Et j'ajouterai une fonction dimage_transform() pour dessiner avec transformation (rotation 90, rotation 180, rotation 270, miroir, upscale, simultanément si on veut). Ce sera pas hyper rapide mais ce sera hyper souple.

Ça te paraît pas mal ?

Right donc non y'a pas encore de quoi faire les rotations mais ça ne saurait tarder du coup, le temps que je m'alloue de retourner sur gint...
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 10/02/2020 18:45 | #


Oui ça me semble bien
Tu peux en profiter pour implémenter des transformations de couleur peut-être ? (addition de couleurs)
Pour la syntaxe de dimage_trans(), j'imagine une liste d'arguments fixe pour chaque paramètre.
Merci pour ton suivi
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 10/02/2020 18:56 | #


Kikoodx a écrit :
Tu peux en profiter pour implémenter des transformations de couleur peut-être ? (addition de couleurs)

Hmm, ouais on doit pouvoir faire ça ! Mais faut bien spécifier les opérations alors. Si possible j'aimerais éviter de séparer les composantes RGB parce que ça va être vachement lent pour le coup. Mais on peut toujours le coder, faudra juste l'utiliser avec parcimonie.

Pour la syntaxe de dimage_trans(), j'imagine une liste d'arguments fixe pour chaque paramètre.

Il y a plusieurs possibilités, soit tu combines juste les valeurs, ce qui suffit quand il n'y a qu'un nombre fini de combinaisons :

dimage_transform(x, y, &img, DIMAGE_ROTATE(90) | DIMAGE_SCALE(2));

Soit tu mets des arguments variables mais dans ce cas-là il faut un terminateur :

dimage_transform(x, y, &img, DIMAGE_ROTATE(90), DIMAGE_SCALE(2), 0);

Soit tu mets un argument par paramètre, même ceux qui sont inutilisés :

dimage_transform(x, y, &img, /* rotate */ 90, /* scale */ 2, /* mirror */ 0, /* color effect */ 0);

Soit tu utilises une structure pour spécifier ça :

struct dimage_tr opt = {
    .rotate = 90,
    .scale = 2,
    /* Other members initialized to "no transform" by default */
};
dimage_transform(x, y, &img, &opt);

Et dans ce cas tu peux profiter de la syntaxe inline de GCC :

dimage_transform(x, y, &img, (struct dimage_tr){ .rotate = 90, .scale = 2 });

Et j'en ai encore d'autres. Bref, y'a le choix.

Cela dit ce serait bien si ça reste cohérent avec les options de dessin que je vais ajouter pour choisir proprement la couleur des lignes, les bordures de rectangles, l'alignement du texte, etc etc.
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 11/02/2020 09:44 | #


Vu ce que tu proposes j'aurai tendance à préférer la structure, ça permettrait d'avoir des paramètres "globaux" aux transformations (le fameux x2).
Pour les couleurs je pense que juste rendre "plus clair" ou "plus foncé" suffirait, ça permettrait déjà de faire des effets sympas.
Peut-être même dessiner le sprite entier d'une couleur unie (pour les effets de hit par exemple).
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

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


Pour les couleurs je pense que juste rendre "plus clair" ou "plus foncé" suffirait, ça permettrait déjà de faire des effets sympas.

Hmm c'est pas facile, c'est de l'arithmétique de saturation... mais je peux peut-être tricker complètement avec des jeux de bits. Il faudrait que j'essaie pour te dire si c'est possible.

Peut-être même dessiner le sprite entier d'une couleur unie (pour les effets de hit par exemple).

Ah oui bien ! Ça c'est facile !

Ajouté le 11/02/2020 à 10:20 :
Bon j'ai une idée pour éclaircir efficacement, et je pense que ça préserve à peu près les couleurs (en linéaire... pas en SRGB ; mais tant pis). Ça ressemble à ça. x)

double = input << 1;
saturated = (((double & 0x10820) x 31) >> 5) | (double & 0xf7de) | (input & 0x0821);

Faudra tester en détail. Ce qui est sûr c'est que éclaircir ou assombrir avec un niveau personnalisé c'est (trop) compliqué.

Ajouté le 11/02/2020 à 10:41 :
J'ai pas pu m'empêcher d'essayer. Si je me suis pas trompé je peux doubler la valeur de toutes les composantes RGB (avec infime approximation) en 6 lignes d'assembleur par pixel. x)

Initialization:
    mov.l    #0x00010820, r8
    mov    #5, r9
    mov    #-5, r10

Iteration:
    # Load pixel
    mov.w    <pixel>, r0
    extu.w    r0, r0

    # Saturate pixel
    shll    r0
    and    r8, r0
    mov    r0, r2
    shad    r9, r0
    sub    r2, r0
    shad    r10, r0

    # Paint pixel
    mov.w  r0, <vram>
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 11/02/2020 12:13 | #


Je comprend rien à l'assembleur mais super

Edit : Comment inclure memcpy ? J'en ai besoin pour mon programme et #include <gint/std/memory.h> ne fonctionne pas.

Ajouté le 11/02/2020 à 13:41 :
J'ai trouvé tout seul, j'incluais le mauvais header my bad
(C'était gint/std/string.h)
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 11/02/2020 14:04 | # | Fichier joint


En plus ça marche ! Et j'ai pu simplifier la formule. Je mets ça là si quelqu'un en a l'usage...

/* Éclaircir */
bright = input << 1;
bright = bright | (((bright & 0x10820) * 31) >> 5);
/* Assombrir */
dark = (input >> 1) & 0x7bef;

Et donc voilà ce que ça donne sur une image full-res.

Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 13/02/2020 15:58 | #


Bonjour
J'aimerais savoir si l'affichage d'une image avec fond transparent est plus rapide sur CG-50 qu'avec un fond de couleur unie.
Merci d'avance !
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 13/02/2020 16:05 | #


Une question super intéressante que j'ai du benchmarker pour tester !

La réponse est ça ne fait aucune différence parce que la RAM est le facteur limitant, et donc on a le temps de tester la transparence pendant qu'elle travaille (en gros).

Pour cette raison, j'espère (sauf dans les cas où la méthode sans transformation effectue des optimisations spéciales) que le surcoût des transformations sera pas trop important durant le dessin.

Par comparaison, le choix de l'encodage fait bien plus de différence. Pour une grande image, il faut privilégier les modes à palette. p8 va environ 20% plus vite et p4 40% plus vite à dessiner en plein écran.
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 13/02/2020 16:12 | #


Pratique ! Merci beaucoup pour ta réponse
Comment utiliser les modes à palette ? Cela pourrait être intéressant, mon jeu se limite à 16 couleurs au total.
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 13/02/2020 16:14 | #


Dans ton projet.cfg, ajoute une option profile aux images. Par exemple, cette option :

IMG.player.png = profile:p4

Utilisera la palette 4-bit pour player.png.

Il y a un exemple en bas du fichier, je crois.
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 13/02/2020 16:21 | #


OK merci

Ajouté le 14/02/2020 à 10:12 :
Ça m'a l'air de fonctionner, j'aimerais demander s'il est possible d'appliquer des paramètres par défaut à un type de fichier ?
Du type IMG.DEFAULT = profile:p4, ce serait plus pratique dans les jeux qui utilisent peu de couleurs par défaut (pour le moment je dois faire une ligne pour chaque fichier manuellement).
Merci d'avance
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 14/02/2020 10:25 | #


Je me doutais que tu allais demander hé hé. xD

Non, ce n'est pas encore possible, mais je pense que ça a toutes les raisons de l'être. Si tu as un petit moment, tu peux poster une issue pour discuter des détails et t'assurer que j'oublie pas.
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 14/02/2020 10:48 | #


https://gitea.planet-casio.com/Lephenixnoir/fxsdk/issues/3
Voilà qui est fait
Merci !
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 14/02/2020 11:19 | #


Merci ! (J'ai répondu, ça va se faire vite je pense.)

Du coup j'ai vérifié, dans bopti sur Graph 90+E il n'y a que le format r5g6b5 qui exploite un accès 32-bit à la VRAM. Donc à part ce cas-là, les transformations devraient pas être significativement plus lentes.

Sur monochrome par contre, ça pourrait être 100 fois plus lent... o(x_x)o
Kikoodx En ligne Membre Points: 2149 Défis: 11 Message

Citer : Posté le 14/02/2020 14:52 | #


Merci à toi !
C'est une bonne nouvelle !
J'avais une autre idée de "transformation", serait-il possible de dessiner des images avec un niveau d'alpha variable ? (i.e. l'effet de mort dans Gravity Duck Prizm)
Merci d'avance
2+2=5
Perdu
Lephenixnoir En ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 14/02/2020 15:14 | #


Aha ! Eh... c'est possible mais ça c'est "très dur" par contre. Je peux le coder c'est pas un problème, mais ce sera lent.

La composition avec transparence (alpha compositing, je ne sais pas comment le dire mieux) c'est très calculatoire. D'abord il faut décomposer les couleurs en canaux, pas moyen de tricher avec la représentation binaire. Ensuite, en principe, il faut sortir de l'espace RGB et aller dans le linéaire pour faire la composition. Donc il faut jouer de l'exponentation avec le gamma. Tu peux approximer ça en des carrés et des racines carrées. Une fois composé (quelques multiplications et additions), il faut revenir du linéaire vers le RGB et recomposer les couleurs.

Tu rentres dans le traitement d'images à proprement parler.

Il me semble que dans Gravity Duck Prizm il fait pas ça (?), de mémoire le sprite du canard fond au blanc et ensuite soit il disparaît immédiatement soit le blanc se fond dans le décor. C'est très différent sur le plan calcul.
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 32, 33, 34, 35, 36, 37, 38 ··· 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 60 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