gint : un noyau pour développer des add-ins
Posté le 20/02/2015 17:30
Ce topic fait partie de la série de topics du fxSDK.
En plus des options de programmation intégrée comme le Basic Casio ou Python, la plupart des calculatrices Casio supportent des
add-ins, des programmes natifs très polyvalents avec d'excellentes performances. Les add-ins sont généralement programmés en C/C++ avec l'aide d'un ensemble d'outils appelé SDK.
Plusieurs SDK ont été utilisés par la communauté avec le temps. D'abord le
fx-9860G SDK de Casio avec fxlib pour Graph monochromes (plus maintenu depuis longtemps). Puis le
PrizmSDK avec libfxcg pour Prizm et Graph 90+E (encore un peu actif sur Cemetech). Et plus récemment celui que je maintiens, le
fxSDK, dont gint est le composant principal.
gint est un unikernel, ce qui veut dire qu'il embarque essentiellement un OS indépendant dans les add-ins au lieu d'utiliser les fonctions de l'OS de Casio. Ça lui permet beaucoup de finesse sur le contrôle du matériel, notamment la mémoire, le clavier, l'écran et les horloges ; mais aussi de meilleures performances sur le dessin, les drivers et la gestion des interruptions, plus des choses entièrement nouvelles comme le moteur de gris sur Graph monochromes.
Les sources de gint sont sur la forge de Planète Casio :
dépôt Gitea Lephenixnoir/gint
Aperçu des fonctionnalités
Les fonctionnalités phares de gint (avec le fxSDK) incluent :
- Toutes vos images et polices converties automatiquement depuis le PNG, sans code à copier (via fxconv)
- Un contrôle détaillé du clavier, avec un GetKey() personnalisable et un système d'événements à la SDL
- Une bibliothèque standard C plus fournie que celle de Casio (voir fxlibc), et la majorité de la bibliothèque C++
- Plein de raccourcis pratiques, comme pour afficher la valeur d'une variable : dprint(1,1,"x=%d",x)
- Des fonctions de dessin, d'images et de texte optimisées à la main et super rapides, surtout sur Graph 90+E
- Des timers très précis (60 ns / 30 µs selon les cas, au lieu des 25 ms de l'OS), indispensables pour les jeux
- Captures d'écran et capture vidéo des add-ins par USB, en temps réel (via fxlink)
Avec quelques mentions spéciales sur les Graph monochromes :
Un moteur de gris pour faire des jeux en 4 couleurs !
La compatibilité SH3, SH4 et Graph 35+E II, avec un seul fichier g1a
Une API Unix/POSIX et standard C pour accéder au système de fichiers (Graph 35+E II seulement)
Et quelques mentions spéciales sur les Graph 90+E :
Une nouvelle police de texte, plus lisible et économe en espace
Le dessin en plein écran, sans les bordures blanches et la barre de statut !
Un driver écran capable de triple-buffering
Une API Unix/POSIX et standard C pour accéder au système de fichiers
Galerie d'add-ins et de photos
Voici quelques photos et add-ins réalisés avec gint au cours des années !
Arena (2016) — Plague (2021)
Rogue Life (2021)
Momento (2021)
Communication avec le PC (cliquez pour agrandir)
Utiliser gint pour développer des add-ins
Les instructions pour installer et utiliser gint sont données dans les divers tutoriels recensés dans le
topic du fxSDK. Il y a différentes méthodes de la plus automatique (GiteaPC) à la plus manuelle (compilation/installation de chaque dépôt). Le fxSDK est compatible avec Linux, Mac OS, et marche aussi sous Windows avec l'aide de WSL, donc normalement tout le monde est couvert
Notez en particulier qu'il y a des
tutoriels de développement qui couvrent les bases ; tout le reste est expliqué dans les en-têtes (fichiers
.h) de la bibliothèque que vous pouvez
consulter en ligne, ou dans les ajouts aux changelogs ci-dessous.
Changelog et informations techniques
Pour tester les fonctionnalités et la compatibilité de gint, j'utilise un add-in de test appelé gintctl (
dépôt Gitea Lephenixnoir/gintctl). Il contient aussi une poignée d'utilitaires d'ordre général.
Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et des liens vers des instructions/tutoriels supplémentaires qui accompagnent ces versions.
Anecdotes et bugs pétés
Ô amateurs de bas niveau, j'espère que vous ne tomberez pas dans les mêmes pièges que moi.
TODO list pour les prochaines versions (2023-04-03)
gint 2.11
- Changements de contextes CPU. À reprendre du prototype de threading de Yatis pour permettre l'implémentation d'un véritable ordonnanceur. Demandé par si pour faire du threading Java.
- Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
- Support de scanf() dans la fxlibc. Codé par SlyVTT, plus qu'à nettoyer et fusionner.
Non classé
- Regarder du côté serial (plus facile que l'USB) pour la communication inter-calculatrices (multijoueur) et ultimement l'audio (libsnd de TSWilliamson).
- Un système pour recompiler des add-ins mono sur la Graph 90+E avec une adaptation automatique.
- Support des fichiers en RAM pour pouvoir utiliser l'API haut-niveau sur tous les modèles et éviter la lenteur de BFile à l'écriture quand on a assez de RAM.
Citer : Posté le 29/03/2022 13:44 | #
Oui si tu lis sur la même machine ça marche. Je voulais dire que si tu fais ça une sauvegarde sur Casio et une sauvegarde sur Nspire (c'est little-endian une Nspire right?) ne seraient pas interchangeables.
Citer : Posté le 29/03/2022 13:49 | #
Bon, suis-je le premier à utiliser le fopen() / fread() / fwrite() après toi ?
Pour fopen() et fread() j'ai fais un programme de test ya un mois ou deux
Citer : Posté le 29/03/2022 14:06 | #
Oui si tu lis sur la même machine ça marche. Je voulais dire que si tu fais ça une sauvegarde sur Casio et une sauvegarde sur Nspire (c'est little-endian une Nspire right?) ne seraient pas interchangeables.
oui c'est du little-endian chez TI. Effectivement si je translate, faudra que je fasse gaffe. Bien vu.
Pour fopen() et fread() j'ai fais un programme de test ya un mois ou deux
Cool. Bon tu vois Lephé, déjà 2 utilisateurs
Ajouté le 29/03/2022 à 14:13 :
Je me rends compte que j'ai pas donné mes priorités pour gint
Pour moi en vraiment utile car c'est un peu l'agonie avec OutRun :
1/ les images optimisées pour essayer de passer sans overclock, car là ça fout la machine sur les genous
2/ l'overclock (ca pourrait même devenir la P1, selon ce qu'on peut espèrer sur les images optimisées), si besoin Lephé, je peux te lister les paramètres de PTune3 pour les configs présentes en standard.
3/ scanf et Cie.
4/ son ? serial ? mais à plus long terme
Voili voilou
Sly
Citer : Posté le 30/03/2022 12:50 | #
Une solution d'overclock m'interesserait aussi beaucoup pour les graphes 3d dans KhiCAS...
Citer : Posté le 16/04/2022 15:02 | # |
Fichier joint
Update rapide sur l'imagerie : j'ai recodé pas mal de détails pour isoler le code de rendu en assembleur d'Azur et le passer dans gint (dans ce cas il utilisera toujours la VRAM, ce qui sera lent, mais au moins il y aura les transformations). Je viens de finir de debugger les transformations HFLIP et VFLIP sur les formats 16-bit (rien de très violent, mais c'est là) :
L'overclock a aussi été super bien préparé par Slyvtt, dès que je mettrai les mains dedans ça devrait être implémenté presque immédiatement.
Citer : Posté le 16/04/2022 19:46 | #
Maintenant que j'ai récupéré ma Cg-20, je vais préparer l’equivalent en overclock que pour la Cg-50/G90+E.
A priori juste les paramètres à ajuster, mais avec la machine dispo et les sources de Sentaro21, je suis très confiant.
Il ne manquera plus que les fx9860 après...
Citer : Posté le 18/04/2022 23:27 | #
Encore des bonnes nouvelles ! SlyVTT fait plein de choses (dont une tentative sur le port de la SDL 1.2 actuellement !), et pendant ce temps-là j'ai fini les effets de couleur sur les formats 16-bit pour gint 2.8.
On a essentiellement deux effets : CLEARBG qui efface une des couleurs, et SWAPCOLOR qui remplace une couleur par une autre. Les images avec transparence sont juste un cas particulier de CLEARBG. Pour les images avec transparence, on peut aussi utiliser SWAPCOLOR pour ajouter un fond d'une couleur choisie (auquel cas ça s'appelle SETBG).
Bien sûr, à ces effets s'ajoutent les miroirs horizontal et vertical.
Il me reste encore des trucs à faire niveau méta (genre une vérification automatique que tous les pixels sont bons, à vue je me fais avoir des fois, et de quoi mesurer les perfs de façon automatique), mais sinon c'est bon.
Les formats P8 et P4 seront plus faciles, P8 est essentiellement déjà fait, y'a juste une partie dure au niveau de P4 où faut que j'améliore la version CLEARBG et ça va être non trivial. Pour ces formats là SWAPCOLOR ce sera juste un swap de palette.
Ensuite modifier le format d'images pour faire comme libimg, etc etc.
Citer : Posté le 19/04/2022 07:59 | #
Yo,
cool
Très intéressant et surtout très très prometteur.
Hâte que tout cela arrive en prod soon.
Qu'est-ce qui explique la différence entre les temps pour a priori les mêmes opérations via AZUR :
- time 0:02 / 0:24 : azur (XVRAM) 16-bits Opaque NONE : 1041 µs
- time 0:08 / 0:24 : azur (XVRAM) 16-bits Opaque NONE : 772 µs
visiblement tous les indicateurs cmdgen / sort / shaders gagnent. Il y a une forme de mise en cache qui intervient qq part ?
Si on prend comme ref les 1176 µs du départ avec bopti (VRAM), on gagne ~10% mini et jusqu'à ~35% maxi (ce qui est vraiment impressionnant)
Lephé : il y a aussi Hackcell qui bosse sur la partie 'scanf' si j'ai bien compris.
Concernant la cSDL (chez TI sur la nSpire on a la nSDL) donc là je regarde pour avoir la cSDL en effet), bon c'est pas pour tout de suite je pense, y'a pas mal de taf, et j'en découvre tout le temps un peu plus que je n'avais pas répertorié
Du coup en trucs pas entamés (encore), il reste juste les 'Serial Coms' et le son via 3-pin par rapport à la liste ici
Citer : Posté le 19/04/2022 08:54 | #
Lephé : il y a aussi Hackcell qui bosse sur la partie 'scanf' si j'ai bien compris.
À moins que tu puisse attendre un an ou deux pour le plus gros elan de motiv' que j'ai jamais eu (et qu'il ne soit pas pris par un autre projet) pas vraiment X)
J'ai juste fais readline(3) parce que je me suis dis que j'en aurais probablement besoin et que la quantité d'effort pour l'implémenter etait pas trop importante
Citer : Posté le 19/04/2022 09:21 | #
Lephe : puis je proposer deux ajouts dans fxlink ?
- 1 / sortie dans un fichier via un '-file nomfichier'
- 2 / avoir une sortie minimale sans reprise du protocol : afin que lorsqu'on envoie du texte, seul le texte reçu soit affiché dans la console/le fichier sans autre chose (pour connecter plus facilement à un autre programme par exemple).
Citer : Posté le 19/04/2022 10:43 | #
Le cache de la RAM en lecture. La bonne valeur est la seconde
Note aussi que dans le temps indiqué pour bopti il n'y a que le rendu des images, alors que dans celui indiqué pour Azur il y a aussi le azrp_clear() qui occupe 400 µs de shaders. Sur l'exemple que je montre ça fait une très grande différence, le 1050 µs de rendu est en fait juste 650 µs !
Ici ça marche très très bien parce que l'image de l'arbre rentre aisément dans le cache en RAM. bopti(VRAM) fait 830 µs, azur(XYRAM) fait 370 µs, donc c'est large. Mais c'est le cas le plus favorable : sur les très grandes images (qui contrairement à l'arbre ne tiennent pas en cache) le gain est plus faible puisque la lecture de l'image est limitante, et sur les formats plus compliqués bopti conserve quasiment ses perfs puisqu'il est en fait limité par l'écriture en RAM partout. Mais pour l'instant sur tous mes tests (qui contient des grosses images mais pas encore de formats plus subtils) je gagne au moins 15% partout.
J'ai ajouté la TODO list dans le post principal.
- 1 / sortie dans un fichier via un '-file nomfichier'
- 2 / avoir une sortie minimale sans reprise du protocol : afin que lorsqu'on envoie du texte, seul le texte reçu soit affiché dans la console/le fichier sans autre chose (pour connecter plus facilement à un autre programme par exemple).
Je note ça. Cela dit un fichier unique en sorte ça ne marche que pour le texte.
Note qu'un des objectifs de fxlink c'est de te donner la main sur le post-traitement, ie. si tu envoies un message avec un autre nom d'application que fxlink ça doit appeler un programme externe, auquel cas tu peux faire ce que tu veux. (Je sais plus si c'est codé pour l'instant.)
Citer : Posté le 19/04/2022 11:03 | #
Donc si je me rappelle bien, on a 8Ko de cache rapide pour Azur, si on part sur un équivalent P8 codé donc sur 1byte, on pourrait avoir un tileset "hyper rapide" de 32 tiles 16x16pixels (ou 16 tiles 16x16 en RGB565 si on perd trop de perf pour le passage P8->RGB565).
C'est plutôt pas mal.
Je note ça. Cela dit un fichier unique en sorte ça ne marche que pour le texte.
Oui pardon, c'est effectivement juste pour le texte ma demande. Je regarderai éventuellement si je sais faire, j'avoue pas avoir regardé pour le moment, a priori ça devrait pas être trop trop complexe.
Note qu'un des objectifs de fxlink c'est de te donner la main sur le post-traitement, ie. si tu envoies un message avec un autre nom d'application que fxlink ça doit appeler un programme externe, auquel cas tu peux faire ce que tu veux. (Je sais plus si c'est codé pour l'instant.)
Là je vois pas comment
Citer : Posté le 19/04/2022 11:10 | #
Donc si je me rappelle bien, on a 8Ko de cache rapide pour Azur, si on part sur un équivalent P8 codé donc sur 1byte, on pourrait avoir un tileset "hyper rapide" de 32 tiles 16x16pixels (ou 16 tiles 16x16 en RGB565 si on perd trop de perf pour le passage P8->RGB565).
C'est plutôt pas mal.
La XRAM et la YRAM font 16 ko à deux mais Azur en utilise la majorité ; en réalité, le bénéfice de ces mémoires c'est surtout en écriture. En lecture, tu as 32 ko de cache RAM qui est aussi rapide que la XRAM/YRAM. Même si bien sûr en réalité il n'y pas que les images que tu lis qui sont dans le cache, il y a aussi une partie de la pile etc.
Mais donc tu as généralement plus que 8 ko, par contre pas énormément de contrôle.
Edit : Et en plus le cache choisit dynamiquement ce qu'il contient, ce qui veut dire que t'as rien à faire pour passer d'un tileset à un gros sprite ou autre. Mais que si tu tournes beaucoup les données tu perds tout.
Oui ça c'est pas dur, tu peux regarder la fonction appelée après la réception d'un message, c'est très explicite et tu peux rediriger vers un fichier.
Il faut créer le header toi-même. Si tu regardes le code de usb_fxlink_text(), outre l'alignement qui est un peu tordu (et un peu faux aussi), y'a juste un header avant le message, et là-dedans "fxlink" c'est l'application et "text" c'est le type ; l'idée (tu peux le voir dans la fonction fxlink que j'ai liée ci-dessus) c'est que pour les autres applications on peut appeler un programme externe et lui filer les données. Actuellement je sauvegarde tout dans un "blob", le truc est pas codé (mais c'est pas dur).
Citer : Posté le 19/04/2022 11:41 | #
Ok, je vais regarder cela. Effectivement y'a moyen de bricoler qq chose.
Je pense que je vais rajouter une application "file" qui aura juste comme type "text" et fera le pipeline.
Idem avec "fxlink_minimal" qui aura les divers types et enlevera les "fioritures"
Ce genre de trucs, je garde perso ou je push le dev ?
Car c'est du 'bricolage' par rapport à mes besoins, je sais pas si ça correspond à d'autres besoins d'utilisateurs.
Citer : Posté le 19/04/2022 11:51 | #
Right donc tout ce qui est par défaut ça doit être dans l'appli "fxlink", par principe pour l'organisation.
Je pense que ce serait bien de supporter un type log dans l'appli fxlink, qui se comporte comme text mais renvoie vers un fichier, avec soit un nom spécifié sur la ligne de commande (fxlink -i -w --fxlink-log=whatever.log) soit rien de spécifié et un nom automatique (le classique avec la date sauf que y'en a qu'un pour toute l'exécution et tout est ajouté dedans ensuite).
En plus de ça, une option de ligne de commande pour ne pas afficher les messages à la con genre "nouveau paquet reçu" serait utile en elle-même.
Tout ça c'est bienvenu à pousser oui, tu peux le faire plus ou moins bourrin sur un fork et ensuite proposer une PR, ensuite j'ajusterai si y'a des détails qui me préoccupent. Si tu fais ça pense à partir de la branche dev.
Ajouté le 23/04/2022 à 17:41 :
Du nouveau sur les effets dynamiques : j'ai réalisé que l'effet "dye" consistant à colorer tous les pixels non transparents d'une image avec une couleur unique pouvait facilement être fait de façon dynamique, donc je l'ai programmé.
Ça fait donc, pour le 16 bits :
Sur ce je vais repasser au 8-bit et au 4-bit.
Citer : Posté le 25/04/2022 00:58 | # |
Fichier joint
Update rapide : j'ai fait la majorité du boulot sur P8 (à savoir 3 des 4 fonctions), et j'ai également réarrangé le code pour que les effets soient séparés ; ainsi, on aura des fonctions du style dimage_rgb16_dye(...) ce qui permettra de ne pas se trimballer le code de tous les effets pour tous les formats dans chaque add-in (la fonction générique sera quand même disponible si ça vous est égal).
Voilà en gros ce qui est fait :
Ça fait trop longtemps que je suis là-dessus, j'ai vraiment envie d'en finir.
Citer : Posté le 28/04/2022 12:31 | # |
Fichier joint
Du nouveau ; j'ai peaufiné en surface, y compris mon tableur (ci-dessous) qui est dans sa forme finale pour la publication de la fonctionnalité.
J'ai aussi programmé l'effet manquant pour P8 (SWAPCOLOR/ADDBG), ainsi que l'infra générale pour P4 avec l'affichage normal et une version préliminaire (pas encore debuggée) de CLEARBG. Vous pouvez aussi voir les indications de performance.
Comme j'approche de la fin de ces effets (et je compte essayer de pousser un gros coup aujourd'hui), voici une liste approximative de ce que la release va contenir en termes de gestion d'images sur Prizm / Graph 90+E. Si j'ai oublié votre fonctionnalité préférée (c'est possible), n'hésitez pas à demander.
Détails importants
Des changements dans la structure d'images ; rien de très visible pour vous, mais ça permet la majorité du reste. Il faudra reconvertir toutes les images avec fxconv (ie. recompiler entièrement les projets), et les gens qui accèdent aux images directement devront modifier leur code.
Sur les performances, n'attendez pas de miracles ; le bottleneck actuel est la RAM. La seule solution que je peux proposer pour les gens qui sont vraiment limités par le rendu c'est soit d'overclock soit d'utiliser (quand ce sera complètement propre) le système de rendu d'Azur.
Fonctions de rendu d'images
Aucun changement sur dimage() et dsubimage(), mais des nouvelles fonctions de rendu seront ajoutées, je pense à :
d[sub]image_{rgb16,p8,p4}()
// Rendu avec un effet de couleur (HFLIP/VFLIP autorisés)
d[sub]image_{rgb16,p8,p4}_{clearbg,swapcolor,addbg,dye}()
// Rendu avec n'importe quel effet (lourd)
d[sub]image_{rgb16,p8,p4}_effect()
// Rendu avec n'importe quel effet et format (bien bien lourd)
d[sub]image_effect()
Les effets dynamiques en eux-mêmes
Les effets géométriques, cumulables en toutes circonstances :
Les effets de couleurs, dont un seul peut être appliqué à la fois :
Fonctions de manipulation d'images
Je compte importer la majorité des fonctions de libimg. Le système ne sera pas tout à fait aussi souple (notamment parce que libimg n'a que du 16-bit et certaines fonctions ne pourraient pas être refaites aisément pour P8 et P4), mais je garantis au moins qu'il y aura de quoi créer des images et des références à des sous-images, accéder aux pixels, les modifier, et quelques transformations pré-écrites.
À une époque je voulais garder gint "assez petit" dans le sens où je ne voulais pas trop mélanger le kernel et les fonctions très haut niveau. Mais maintenant je m'en fous pas mal, notamment parce que c'est chiant d'avoir des libs externes partout. (Stay tuned pour la fusion libprof → gint qui arrivera certainement.)
Du coup, je pense enrichir le code au fur et à mesure ; par exemple la fonction de rotation + agrandissement utilisée dans After Burner sera très certainement intégrée à gint (surtout que je l'ai bien optimisée en assembleur !).
Citer : Posté le 28/04/2022 14:19 | #
Je suis très enthousiaste pour cette mise à jour, bravo pour tout !
Je pensais comprendre comment le système fonctionne, mais avec les signatures de fonctions que tu présentes je n'en suis plus certain. Comment sont formulées les transformations ? Est-ce qu'on peut combiner HFLIP, CLEARBG et deux SWAPCOLOR par exemple ? Merci ^^'
Citer : Posté le 28/04/2022 14:57 | #
Merci ! Je suis content que ce soit fait aussi, ça répond à plein de demandes restées un peu dans l'ombre.
Je pensais comprendre comment le système fonctionne, mais avec les signatures de fonctions que tu présentes je n'en suis plus certain. Comment sont formulées les transformations ? Est-ce qu'on peut combiner HFLIP, CLEARBG et deux SWAPCOLOR par exemple ? Merci ^^'
On ne peut pas faire ça non. Tu as le droit à HFLIP, VFLIP, et maximum un effet de couleur. Mais pour l'exemple, si tu veux faire un SWAPCOLOR avec HFLIP en P8, ça donnerait ça :
// Note: IMAGE_SWAPCOLOR est implicite
dimage_p8_swapcolor(x, y, &img, IMAGE_HFLIP, color_1, color_2);
// Option 2 : effet générique
dimage_p8_effect(x, y, &img, IMAGE_HFLIP | IMAGE_SWAPCOLOR, color_1, color2);
La différence c'est que si tu utilises dimage_p8_effect() tu vas linker les fonctions pour tous les effets P8 dans ton add-in, ce qui peut être un peu lourd.
La raison pour laquelle ce n'est pas supporté, c'est que pour atteindre des performances sérieuses le calcul de l'effet (ie. transparence, remplacement d'une couleur, etc.) est complètement, totalement entrelacé avec les accès mémoire et le décodage des pixels. Moralement, on a l'impression que l'action de faire un rendu avec SWAPCOLOR et HFLIP se décompose en étapes bien indépendantes et personnalisables :
Mais en réalité, si tu regardes le code de la boucle centrale, tu peux voir que les étapes sont complètement mélangées, sans parler du fait que chaque tour traite 2 pixels et que le traitement de chaque pixel est étalé sur 2 tours :
mov \TMP2, r0
cmp/eq \TMP1, r11 // Étape 4 (pixel #1)
mov.w @(r0, r9), r0 // Étape 3 (pixel #2)
and r8, r10 // Étape 4 (pixel #2)
nop
xor r10, r0 // Étape 4 (pixel #2)
nop
mov.w r0, @(\OFF1, r5) // Étape 5 + 2 (pixel #2)
add #\LOCAL_STRIDE, r5 // Étape 5 + 2
mov.b @r3+, \TMP2 // Étape 1 (pixel #2)
subc r10, r10 // Étape 4 (pixel #1)
add \TMP1, \TMP1 // Étape 3 (pixel #1)
mov \TMP1, r0
mov.w @(r0, r9), r0 // Étape 3 (pixel #1)
cmp/eq \TMP2, r11 // Étape 4 (pixel #2)
mov.b @r3+, \TMP1 // Étape 1 (pixel #1)
and r8, r10 // Étape 4 (pixel #1)
xor r10, r0 // Étape 4 (pixel #1)
nop
mov.w r0, @(\OFF2, r5) // Étape 5 (pixel #1)
3: add \TMP2, \TMP2 // Étape 3 (pixel #2)
Et du coup chaque effet de couleur c'est une fonction à part (avec deux versions selon si HFLIP est utilisé). La philosophie des effets dynamiques tels que je les ai codés pour l'instant, c'est « voici ce que je peux vous proposer qui est essentiellement aussi rapide que l'affichage normal ».
J'ai bien envisagé l'option d'insérer des calculs personnalisés au milieu de la boucle, ce que tu peux voir sur la tout dernière ligne du tableur, "Custom inner loops". L'idée c'est que gint fournirait le squelette de la boucle ci-dessus et tu pourrais remplir. Mais comme tu peux le voir, d'une part c'est compliqué d'écrire le code optimisé, d'autre part si tu veux CLEARBG et deux SWAPCOLOR ensemble ce sera quand même 3-4 fois plus lent que les effets que je propose actuellement.
Je n'ai pas de solution vraiment clean (je rêêêêverais d'écrire un compilateur qui générerait la boucle optimisée automatiquement, mais c'est un peu ambitieux). Là tout de suite si ton besoin c'est de faire un CLEARBG et deux SWAPCOLOR je dirais modifie l'image avant le rendu, là tu peux faire ce que tu veux.
Ah et j'oubliais : si t'utilises un format indexé tu peux remplacer intégralement la palette sans utiliser d'effet et dans ce cas tu as tous les SWAPCOLOR du monde gratuits sans rien demander à personne.
Citer : Posté le 28/04/2022 15:38 | #
Merci pour la réponse détaillée, c'est très clair. J'ai hâte, ça va donner des trucs stylés !
Citer : Posté le 29/04/2022 12:24 | #
Re : j'ai fini tous les effets dynamiques de tous les formats. ENFIN.
Je vais enfin pouvoir m'amuser avec le reste