Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

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: 24575 Défis: 170 Message

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.

VersionDateInfos supplémentaires
gint 2.11.06 Juillet 2024Debuggage à distanceCompilation mono pour Graph 90
gint 2.10.02 Avril 2023
gint 2.9.021 Août 2022
gint 2.8.017 Mai 2022Effets dynamiques sur les imagesAPI de manipulations d'images
Overclock intégré
gint 2.7.119 Mars 2022Tutoriel capture des flux standards
gint 2.7.031 Décembre 2021
gint 2.6.029 Août 2021Tutoriel de capture vidéo par USB
gint 2.5.28 Juin 2021
gint 2.5.12 Juin 2021
gint 2.5.026 Mai 2021Intégration de fxlibc (dépôt) — Tutoriel de communication par USB
gint 2.4.027 Avril 2021Api GINT_CALL() pour les callbacks
gint 2.3.12 Février 2021
gint 2.3.029 Janvier 2021
gint 2.2.112 Janvier 2021
gint 2.2.011 Janvier 2021
gint 2.1.116 Septembre 2020
gint 2.1.021 Août 2020Polices UnicodeNouvelle API du moteur de gris
gint 2.0.3-beta10 Juillet 2020Modifications de l'API timer
gint 2.0.2-beta17 Juin 2020
gint 2.0.1-beta1er Juin 2020

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
  1. 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.
  2. Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
  3. 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.



Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 33, 34, 35, 36, 37, 38, 39, 40 ··· 50 ··· 60 ··· 70 ··· 73, 74, 75 Suivante
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kikoodx Hors ligne Ancien labélisateur Points: 3039 Défis: 11 Message

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


Ah c'est coûteux en effet. Mais ça pourrait être utile dans certaines situations.
L'explosion à la mort du canard m'a l'air d'être un effet de transparence. Le cercle blanc s'affiche en transparence au-dessus des éléments du décor et de fond.
ouais ouais
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

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


Afficher du blanc avec un niveau de transparence variable ça s'imite facilement. Il suffit d'utiliser la formule d'éclaircissement que j'ai montrée plus haut plusieurs fois. (Après 5/6 fois tout devient blanc.)

Tandis qu'afficher une image sur une autre en semi-transparent, ça c'est une autre affaire...
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kikoodx Hors ligne Ancien labélisateur Points: 3039 Défis: 11 Message

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


D'accord. Justement je pense que c'était plus qu'assombrir l'image, mais je dois me tromper si tu le dis

Je pense avoir fait une bêtise, j'ai supprimé build-cg pour le regénérer entièrement (les images n'étaient pas mises à jour), et j'obtiens ces erreurs :
./build.sh
making levels.c
building for cg

:: Making into build-cg

sh-elf-gcc -c src/levels.c -o build-cg/src/levels.c.o -mb -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall -Wextra -Os -D FXCG50  -m4-nofpu -I include -MMD -MT build-cg/src/levels.c.o -MF build-cg/src/levels.c.d -MP
fxconv -i assets-cg/img/ground.png -o build-cg/assets/img/ground.png.o --cg --toolchain=sh-elf name:img_ground profile:p4
fxconv -i assets-cg/img/spike.png -o build-cg/assets/img/spike.png.o --cg --toolchain=sh-elf name:img_spike profile:p4
fxconv -i assets-cg/img/jitem_popup.png -o build-cg/assets/img/jitem_popup.png.o --cg --toolchain=sh-elf name:img_jitem_popup profile:p4
fxconv -i assets-cg/img/jitem.png -o build-cg/assets/img/jitem.png.o --cg --toolchain=sh-elf name:img_jitem profile:p4
fxconv -i assets-cg/img/player.png -o build-cg/assets/img/player.png.o --cg --toolchain=sh-elf name:img_player profile:p4
fxconv -i assets-cg/img/elevator.png -o build-cg/assets/img/elevator.png.o --cg --toolchain=sh-elf name:img_elevator profile:p4
sh-elf-gcc -o build-cg/platform.elf build-cg/src/collide.c.o build-cg/src/player.c.o build-cg/src/draw.c.o build-cg/src/levels.c.o build-cg/src/main.c.o build-cg/assets/img/ground.png.o build-cg/assets/img/spike.png.o build-cg/assets/img/jitem_popup.png.o build-cg/assets/img/jitem.png.o build-cg/assets/img/player.png.o build-cg/assets/img/elevator.png.o -mb -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall -Wextra -Os -D FXCG50  -m4-nofpu -I include  -T fxcg50.ld  -lgint-cg  -lgint-cg -lgcc -Wl,-Map=build-cg/map
sh-elf-gcc: error: build-cg/assets/img/ground.png.o: No such file or directory
sh-elf-gcc: error: build-cg/assets/img/spike.png.o: No such file or directory
sh-elf-gcc: error: build-cg/assets/img/jitem_popup.png.o: No such file or directory
sh-elf-gcc: error: build-cg/assets/img/jitem.png.o: No such file or directory
sh-elf-gcc: error: build-cg/assets/img/player.png.o: No such file or directory
sh-elf-gcc: error: build-cg/assets/img/elevator.png.o: No such file or directory
Makefile:107: recipe for target 'platform.g3a' failed
make: *** [platform.g3a] Error 1
done

En effet, le dossier build-cg/assets/img est vide. Quel est le problème ? Merci d'avance
ouais ouais
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

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


C'est ma faute.

Je l'ai mentionné rapidement sur l'issue, mais le code de p8 et p4 est sur le dépôt... de gint. La partie fxSDK est encore sur mon PC personnel. Donc les fichiers convertis ne sont pas produits...

Je vais pousser tout ça ce soir (dans ~2 heures). Désolé... x)
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kikoodx Hors ligne Ancien labélisateur Points: 3039 Défis: 11 Message

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


C'est drôle je viens de répondre à ton message sur le Gitea, je venais de le comprendre par moi-même x)
Pas de problème o/
ouais ouais
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 19/02/2020 22:29 | #


C'est drôle je viens de répondre à ton message sur le Gitea, je venais de le comprendre par moi-même x)
Pas de problème o/

Hey mais j'ai oublié, il ne fallait pas hésiter à me le rappeler. C'est poussé, tu peux récupérer la branche master et réinstaller le fxSDK pour avoir les profils de couleur p4 et p8 sur fxconv pour Graph 90. Si tu étais sur dev, j'ai fusionné et supprimé la branche (ça rendait encore des gens confus...) donc repasse sur master.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 20/02/2020 14:34 | #


Pour la compilation de gint, j'ai un problème lors du make
-e \e[30;1m>\e[0;1m fxconv\e[0m font5x7.png
  File "/mnt/c/Users/damie/Programmation/gintLibs/bin/fxconv", line 86
    err(f"execution mode -{mode} expects an input file")
                                                      ^
SyntaxError: invalid syntax
Makefile:109: recipe for target 'src/font5x7.png.o' failed
make: *** [src/font5x7.png.o] Error 1

même avec python 3.7.6 (et python3 et python qui sont des alias de python3.7 pour être sur). Je sais pas trop d'ou ca vient, a priori mes libs sont a jour maintenant, et j'ai essayé de supprimer et re-cloner gint, mais cela n'a pas changé; est-ce que ca serait mon installation de fxsdk ou de gcc qui a eu un problème?

Ajouté le 20/02/2020 à 14:35 :
(A noter aussi que lorsque je clone le git de gint j'ai une "warning: remote HEAD refers to nonexistent ref, unable to checkout." et du coup un dossier vide, mais un git checkout compat corrige ce soucis)
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 20/02/2020 14:39 | #


L'endroit de l'erreur est le premier endroit du script où il y a une f-string. Il est clair que le Python qui exécute ce script ne l'a pas reconnu. Ce que tu as fait semble solide, mais il doit rester une arnaque...

Note que les alias ça ne change rien dans un Makefile. Pour savoir ce que make lance il faut désactiver tes alias et utiliser which, ou simplement le bugger avec strace, ou d'autres.

L'histoire du git checkout compat c'est "normal".

Ajouté le 22/02/2020 à 19:12 :
Je viens de pousser un commit qui règle un problème passager avec getkey().

C'est un peu compliqué. Si on appelle getkey() et qu'on appuie sur la touche K, getkey() s'en souviendra. Ça sert à éviter qu'on puisse interférer avec la répétition de K en appuyant sur une autre touche. Cependant, si après avoir obtenu l'information K de getkey() on se met à récupérer des événements autrements (pollevent(), waitevent() ou clearevents()), getkey() peut rater l'information de relâchement de K, auquel cas il continuera injustement de refuser les autres touches.

J'ai ajouté une vérification à l'entrée de getkey() permettant d'éviter ça. Si la dernière touche pressée ne l'est plus quand on entre dans getkey(), alors getkey() se réinitialise.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Milang Hors ligne Membre Points: 488 Défis: 2 Message

Citer : Posté le 23/02/2020 13:20 | #


C'est ça le bug que j'avais signalé plus tôt ! J'utilisais getkey, mais dès qu'il y avait validation, à aucun moment getkey n'enregistrait que la touche de validation avait été pressée puisque je passais en pollevent()
https://dev.planet-casio.com/Fr/forums/topic13572-33-gint-un-noyau-pour-developper-des-add-ins.html#173013

C'est génial ça, je vais pouvoir me remettre à utiliser getkey alors
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

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


Le triple buffering n'était pas encore en place sur Graph 90+E, donc je suis en train de faire ça. Je suis parvenu à mettre en évidence les artefacts visuels qui se produisent si on commence le frame suivant sur la même VRAM, mais uniquement en tordant mon code pour le faire apparaître, et en faisant exprès de dessiner sur la fin de la VRAM, dont je savais pertinemment qu'elle n'était pas encore modifiée.

Voilà donc un constat intéressant pour ceux qui seraient tentés de lancer des gros projets. Il est possible de bénéficier à la fois de la vitesse de transfert du DMA (jusqu'à 10 ms gagnées par frame !) tout en n'utilisant qu'une seule VRAM (170 ko économisés !). Il suffit de commencer chaque frame en dessinant en haut de la VRAM. Par exemple, si on dessine un terrain construit sur un ensemble de tiles, on peut faire ça :
• Envoyer le frame précédent avec dupdate().
• (Optionnel : faire un truc annexe comme le moteur physique ou les IAs pour laisser le DMA prendre de l'avance.)
• Faire le rendu du terrain. Au début de chaque ligne, vérifier dans les registres du DMA que la bande horizontale concernée a déjà été envoyée à la VRAM, et dessiner.
Cette méthodologie aurait pu être présentée bien avant, mais ce que je réalise maintenant c'est que très peu de temps sera perdu, voire pas de temps du tout (bon à part le fait que de toute façon la RAM n'est pas parallèle de toute façon). Et croyez-moi 170 ko de RAM ça peut vous sauver la vie

Voilà voilà, sinon le triple buffering est poussé sur la branche compat, ce qui fait de la pile graphique par défaut de gint l'une des options les plus performantes pour Graph 90+E clé en main. Pour indication, le visualisateur hexa de mémoire de gintctl, une application pas très exigeante en ressources mais dont le code ne fait pas particulièrement attention aux performances, tourne à 43 FPS.

Autres modifications notable :
• Ajout de DWIDTH et DHEIGHT donnant la taille de l'écran (je ne sais plus qui me l'avait demandé)
• Ajout d'une couleur C_RGB(r,g,b) sur Graph 90 (0 ≤ r,g,b ≤ 31)

Ajouté le 23/02/2020 à 16:15 :
C'est ça le bug que j'avais signalé plus tôt !

Je me suis demandé ! Bon ben désolé de pas m'en être rendu compte à ce moment-là. La bonne nouvelle, c'est que keydown() était exactement la solution à ce problème. Maintenant, je suis certain que mon modèle clavier est fiable, robuste et polyvalent. Et ça fait bien 3 ans que j'en tente des variantes dans tous les sens ! xD

Ajouté le 25/02/2020 à 23:50 :
Du progrès sur le retour au menu.

J'ai codé une fonction qui permet de sortir temporairement de gint pour exécuter du code à la fxlib (!). C'est réservé à des cas d'usage très particuliers, à savoir revenir au menu principal et gérer les TLB miss. J'ai bien galéré avec les ETMU, mais ça commence à marcher.

Donc pour l'instant on peut sortir d'un add-in sur monochrome et revenir au menu principal. Il se passe encore des choses bizarres quand on re-rentre (notamment, ça freeze), mais c'est un bon progrès.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Yatis En ligne Membre Points: 581 Défis: 0 Message

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


Donc pour l'instant on peut sortir d'un add-in sur monochrome et revenir au menu principal. Il se passe encore des choses bizarres quand on re-rentre (notamment, ça freeze), mais c'est un bon progrès.

Qu'en est-il du crash qui se produis quand on sort d'un add-in puis qu'on éteint la calto et qu'ont re-entre dans l'add-in ? As-tu une quelconque idée du fonctionnement du mécanisme pour revenir au menu ? Si oui, serait-il préférable de faire nous-mêmes le changement de contexte au lieu de passer par GetKey() (je suppose que non mais je n'ai jamais désassemblé cette partie de l'OS peut-être pourrions-nous trouver un syscall qui fasse le retour menu proprement) ?
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 26/02/2020 11:21 | #


Évidemment comme je ne peux pas rerentrer je n'ai même pas essayé d'éteindre. Chaque chose en son temps !

Selon moi, le retour au menu est un appel de fonction à l'intérieur de GetKey(), et si on sélectionne une appli ça invoque les destructeurs de l'add-in et appelle un syscall pour démarrer la nouvelle application. Donc vu comme ça, effectivement il y a peut-être moyen de ne pas appeler GetKeyWait(). Ce qui aurait deux petits avantages :

1. Pas besoin de s'embêter avec un timer pour injecter KEY_CTRL_MENU.
2. Pas besoin de s'embêter pour faire arrêter GetKeyWait() sans appuyer sur une touche quand on revient dans l'add-in.

J'avoue que ça m'arrangerait bien, et j'ai bien envie de regarder.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kikoodx Hors ligne Ancien labélisateur Points: 3039 Défis: 11 Message

Citer : Posté le 07/03/2020 12:24 | #


Bonjour, y a-t-il une fonction permettant d'obtenir le temps réel en entier de secondes ?
Les fonctions de rtc.h ne permettent d'obtenir qu'une structure, je peux convertir mais c'est galère et pas très utile.
Merci d'avance
ouais ouais
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 07/03/2020 13:46 | #


Pour l'instant il n'y a rien d'autre que rtc.h, mais c'est le bon moment d'en ajouter.

Cela dit tu veux quoi exactement ? Je comprends pas trop le cas d'usage encore...
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Teusner Hors ligne Membre Points: 107 Défis: 0 Message

Citer : Posté le 07/03/2020 21:56 | #


N'y aurait-il pas comme un petit problème ?

$ git clone https://gitea.planet-casio.com/Lephenixnoir/gint.git
Clonage dans 'gint'...
remote: Énumération des objets: 2485, fait.
remote: Décompte des objets: 100% (2485/2485), fait.
remote: Compression des objets: 100% (1325/1325), fait.
remote: Total 2485 (delta 1611), réutilisés 1681 (delta 1078)
Réception d'objets: 100% (2485/2485), 1023.54 KiB | 3.85 MiB/s, fait.
Résolution des deltas: 100% (1611/1611), fait.
warning: la HEAD distante réfère à une référence non existante, impossible de l'extraire.


Autre question : Dois-je me placer dans $PREFIX/include pour clone gint ?
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 07/03/2020 22:14 | #


Il faut git checkout compat pour avoir la branche, il n'y a pas de master actuellement... et c'est un peu stupide, faut vraiment que je la crée même si le truc n'est techniquement pas en release stable.

Autre question : Dois-je me placer dans $PREFIX/include pour clone gint ?

Surtout pas, mets-toi en-dehors de $PREFIX, très en-dehors.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Teusner Hors ligne Membre Points: 107 Défis: 0 Message

Citer : Posté le 07/03/2020 22:17 | #


C'est possible de se mettre dans /tmp pour clone gint ?
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 07/03/2020 22:37 | #


Oui, mais t'as probablement envie de garder le dépôt parce qu'il va falloir que tu récupères les modifications futures. :]

Ajouté le 10/03/2020 à 16:31 :
Avec l'arrivée imminente de libimg, une bibliothèque de manipulation de bitmaps répondant au problème permanent que bopti n'est bon qu'à dessiner dans la VRAM, je vais renommer le type image_t en bopti_image_t, pour éviter la confusion avec l'espace de noms img_* utilisé par libimg, et en particulier le type d'images img_t. De même, le type:image de fxconv va devenir type:bopti-image.

Ça va se faire tranquillement avec des warnings dans un premier temps, et je pense que je ne supprimerai vraiment les anciens termes qu'à la sortie complète de gint, donc pas tout de suite.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kikoodx Hors ligne Ancien labélisateur Points: 3039 Défis: 11 Message

Citer : Posté le 10/03/2020 16:38 | #


Je suis en train de lire le topic de libimg
Vu que tu vas renommer cette variable autant l'appeler bopti_img_t non ? Je pense que ce serait plus cohérent et court.
ouais ouais
Lephenixnoir Hors ligne Administrateur Points: 24575 Défis: 170 Message

Citer : Posté le 10/03/2020 16:41 | #


Hmm c'est plus court c'est vrai, mais d'un côté on a dimage() et type:bopti-image. Je sais pas si c'est plus lisible aussi... mais bon, j'ai le temps de voir.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 33, 34, 35, 36, 37, 38, 39, 40 ··· 50 ··· 60 ··· 70 ··· 73, 74, 75 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
: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 v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 136 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