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 26/07/2015 09:16 | #
Bon, j'ai du nouveau.
Le SH4 n'est sans doute pas un SH7724 mais un SH7305, or ce dernier n'existe tout simplement pas, où que je cherche. Si vraiment ça me branche je taperai au hasard dans les docs de tous les mpus recensés par TeamFX pour trouver le bon mais je lui demanderai quand même, on ne sait jamais.
D'ici là, je suis repassé sur SH3.
La zone mémoire utilisée pour la SH4 fonctionne aussi. Donc l'appel du handler est commun. J'arrive à détecter les pressions de touches mais je ne me suis pas encore penché sur la reconnaissance de la touche.
J'arrive aussi à utiliser un timer de manière tout à fait arbitraite et comme il me plaît. Ça commence à être intéressant.
Ajouté le 26/07/2015 à 16:03 :
J'ai bossé avec l'écran ensuite. ML ne fonctionnait pas. En revanche, la fonction assembleur de kucalc dans revolution-fx, elle, fonctionnait. (Et dire qu'il disait à une époque, « it's already optimized since it's in pure assembleur », il auraît pu optimiser un peu l'assembleur quand même, un compilateur aurait fait presque aussi bien.) Du coup je l'ai réécrite à ma façon (c'est-à-dire plus linéaire et donc compréhensible) et j'arrive à manipuler l'écran.
J'ai mis mes timers, les valeurs de Kristaba sont pas géniales. Du coup je vais publier un add-in de test bientôt. Là, tout de suite, j'ai un dragon en 4 couleurs sous les yeux, c'est l'extase. (voyez le chat s'il n'est pas encore trop tard, Kirafi peut témoigner que je ne mens pas)
Citer : Posté le 26/07/2015 16:08 | #
Citer : Posté le 26/07/2015 16:13 | #
Hey, j'ai le droit d'accord ? Ça fait des mois que j'attends ça !
Ajouté le 27/07/2015 à 13:41 :
Hmph, j'ai un problème conséquent.
Je n'arrive pas à détecter quelle touche est pressée, quand j'ai une interruption. La procédure de SimLo pour détecter quelles touches sont pressées sur une ligne fonctionne bien mais elle a deux inconvénients : elle ne détecte pas deux touches sur la même colonne (elles s'annulent) et surtout, une fois que j'ai fait une analyse, je ne peux plus récupérer d'interruptions que sur la dernière ligne analysée.
J'ai donc opté temporairement au moins pour le syscall 0x24a qui fait ce boulot. Oui, mais il le fait lentement. En tous cas, suffisament pour déranger les timers de façon significative et altérer le gris avec une belle ligne de rafraîchissement à cause du grand nombre d'interruptions générées.
Je suis donc en train de chercher une autre manière de gérer les évènements. Je ne sais pas si on pourra utiliser des fonctions bloquantes, enfin... on verra bien.
Ajouté le 27/07/2015 à 16:37 :
Bon, alors voici les faits au niveau de la gestion du clavier :
→ L'utilisation de fonctions bloquantes et la gestion par interruptions nécessite une routine de détection de la touche
→ La routine de détection de la touche est assez longue pour perturber le gris
→ La fréquence gris est déjà au minimum, plus bas on voir les alternances
Conséquence : utiliser des fonctions bloquantes est en fait... bien mal parti. Kucalc n'a évidemment pas eu ce problème puisque comme il n'avait plus d'interruptions du tout il utilisait des appels de type IsKeyDown().
J'ai pensé à une autre manière de faire qui pourrait être plus légere, en utilisant une sorte de démon avec un timer.
Citer : Posté le 27/07/2015 20:55 | #
Fait gaffe avec les utilisations de démons, déjà que trouver une vierge à sacrifier c'est pas simple, après faut réussir a le renvoyer dans son plan au bout d'un moment
Mais sinon, qu'est ce que t'entend par fonction bloquantes exactement? n'importe quelle fonction, uniquement les fonctions de type getKey, ou autre chose?
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
merci a tout le monde pour son soutien
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 !Citer : Posté le 27/07/2015 21:25 | #
Fait gaffe avec les utilisations de démons, déjà que trouver une vierge à sacrifier c'est pas simple, après faut réussir a le renvoyer dans son plan au bout d'un moment
Oui, ça résume bien le problème... je n'ai trouvé que ça pour l'instant
Mais sinon, qu'est ce que t'entend par fonction bloquantes exactement? n'importe quelle fonction, uniquement les fonctions de type getKey, ou autre chose?
Quand je vois cette question ou les autres que vous me posez des fois, je me rends compte que je dois être incompréhensible la plupart du temps sur ce topic.
Non que les questions ne soient pas pertinentes, mais c'est sûr que pour bosser dessus il faut que ce soit évident pour moi.
Pour lire le clavier, il faut passer par les ports A, B et M du microprocesseur. On envoie un signal sur le port B ou M, qui représentent les lignes (port B pour les lignes 1 à 7, port M pour les lignes 8 et 9) et on récupère les touches pressées pour la ligne en lisant le contenu du port A (le fonctionnement classique pour la gestion des claviers quoi).
Maintenant il y a deux « moments » pour le faire : le premier, c'est quand le programme utilisateur le décide : pour IsKeyDown() ou avec le démon, par exemple. Le seconde, c'est lorsque l'utilisateur appuie sur une touche : cela génère une interruption et on sait alors que l'on peut analyser les ports pour trouver laquelle.
La famille de fonction qui lit les ports au premier des deux moments évoqués est de type IsKeyDown()-0x24a. Elles sont instanées et renvoient leur résultat en lisant les ports. La famille de fonction qui utilise les interruptions est celle de GetKey(). Ces fonctions mettent le microprocesseur en veille avec l'instruction « sleep », et leur exécution s'arrête donc jusqu'à ce qu'une interruption réveille le processeur -sous certains critères. Une fois l'interruption traitée, la fonction continue et si l'interruption était bien du clavier (pas la RTC par exemple) elle s'arrête et renvoie la touche pressée après analyse des ports.
La deuxième famille de fonctions est préférable dans bien des cas parce qu'elle économise de la batterie. Cependant, la procédure d'analyse des ports est encore trop lente et perturbe le gris, parce que les interruptions lorsqu'on appuie sur une touche arrivent continuellement et en grande quantité.
Pour les traiter plus vite, je suis en train d'essayer de faire des optimisations, en particulier tester si on n'est pas sur une répétition de la dernière touche pressée. Pour l'instant, je n'arrive pas à mettre en oeuvre ce test mais j'y travaille. À noter qu'à la base, l'interruption clavier était de même niveau que le timer et prioritaire par défaut, donc quand on appuyait sur une touche le traitement du timer était mis en attente. Les interruptions arrivaient alors assez vite pour figer complètement l'écran sur une des deux images. Après réglage de la priorité, le gris continue mais est ralenti et ce phénomène suffit pour faire apparaître sur mon écran une ligne de rafraîchissement de 10 pixels de large très peu esthétique.
Donc l'idée était d'utiliser un démon tout en sachant que les fréquences du timer gris s'accorderait sur la perte de vitesse générée, mais c'est assez instable : en outre, ça dépend de la vitesse des machines.
Ah et, le contraste joue énormément sur l'aspect du gris. Donc je pense que le moteur le paramètrera lui-même, sans empêcher pour autant le programme utilisateur d'écraser cette configuration plus tard, mais histoire d'assurer un gris correct.
Ajouté le 28/07/2015 à 09:30 :
Pour les traiter plus vite, je suis en train d'essayer de faire des optimisations, en particulier tester si on n'est pas sur une répétition de la dernière touche pressée.
J'ai réussi à faire ça. Pour sûr ça perturbe moins le gris !
Par contre je suis formel, les interruptions du clavier sont générées en continu. Ce phénomène est généralement dû à un oubli dans l'interrupt handler : en effet, il y a souvent un bit dans un registre qui est mis à 1 lorsqu'une interruption est générée et qu'il faut remettre à 0 lorsqu'on traite l'interruption, sans quoi une nouvelle interruption est générée tout de suite, empêchant la reprise de l'exécution du programme utilisateur.
Cependant, là on ne travaille pas avec un module périphérique mais des pins spécifiques appelés PINT0 à PINT7 (il y en a 16 jusqu'à PINT15 au total) qui sont faits pour générer des interruptions (quand on envoie un signal ça génère une interruption, en l'occurrence si PINT0-PINT7 est différent de 0xff ; on retrouve ces valeurs dans le port A donc si vous avez bien suivi l'interruption est envoyée quand une des colonnes a une touche pressée). Et comme ce n'est pas un module périphérique, je ne vois aucun registre ou autre dans lequel un bit serait à effacer. De plus, les interruptions PINT ne sont documentées que sur une dizaine de lignes dans le documentation donc je n'ai pas plus d'informations.
Ajouté le 28/07/2015 à 12:03 :
Bon, c'est bizarre mais je n'arrive à utiliser que le timer 0... quoi que je fasse, les 1 et 2 provoquent des erreurs... c'est bizarre mais toute la configuration que je peux y faire ne change rien...
Ajouté le 28/07/2015 à 12:11 :
Ah, voilà, problème corrigé. C'était bête, je ne comprenais pas pourquoi j'avais une System ERROR de type INTERRUPT quand j'appuyais sur une touche, mais c'était simplement parce que je quittais le programme (quand j'avais une touche je quittais) sans arrêter les timers.
Pour le 0 ça fonctionnait, je sais pas trop pourquoi.
Ajouté le 31/07/2015 à 22:34 :
Ma gestion du clavier est maintenant complète !
C'est pour SH3, j'invite tout ceux qui le peuvent à prendre un quart d'heure pour me confirmer que ça marche bien sur leurs machines : Int. testing
J'ai plein de bonne nouvelles !
→ Le clavier fonctionne (c'est déjà ça !).
→ La gestion des répétitions est parfaite et full-featured : moyennant quelques modifications, on pourra paramétrer la répétition plus rapide de n'importe quelle touche.
→ Rester appuyé sur une touche ne bloque plus le programme utilisateur (important xD ).
→ Le portage sur SH4 ne nécessitera que la gestion des timers (y'a un syscall derrière
→ Le gris n'est plus du tout altéré par le clavier.
Avec ça, le projet avance vite, très vite !
Ajouté le 02/08/2015 à 22:55 :
Quelques nouvelles rapides, je passe en coup de vent : j'ai pas mal avancé le moteur, documenté et nettoyé le code, je passe progressivement d'une API expérimentale à un truc fonctionnel. Dans quelque réglages je m'attaques aux libs de dessin et à leurs trésors d'optimisation.
J'ai mis à jour tout le topic pour plus d'explications, n'hésitez pas à le relire si vous ne comprenez pas forcément le principe du projet et que avez un peu de temps.
Voilà voilà, le clavier se gère bien (avec des define etc.), je vais pouvoir gérer SHIFT facilement, ALPHA non mais on verra en temps voulu.
Le gris aussi est bien, le clavier ne le perturbe pas du tout donc le rendu est très sympa ! Je peux déjà commencer à coder simplement des applications fonctionnelles avec gestion du clavier et de l'écran.
Citer : Posté le 03/08/2015 01:36 | #
D'accord ! En fait tu refais totalement le gestionnaire d'interruption !
Et il est où "physiquement" ce gestionnaire ? Il est dans la ROM, et toi tu vas écrire par dessus comme tu connais son adresse c'est ça ? Comment ça se fait que ce gestionnaire ne soit pas écrit dans l'OS ? (C'est peut être le cas je n'en sais rien
Citer : Posté le 03/08/2015 09:48 | #
D'accord ! En fait tu refais totalement le gestionnaire d'interruption !
Yep
Et il est où "physiquement" ce gestionnaire ? Il est dans la ROM, et toi tu vas écrire par dessus comme tu connais son adresse c'est ça ? Comment ça se fait que ce gestionnaire ne soit pas écrit dans l'OS ? (C'est peut être le cas je n'en sais rien
À vbr + 0x600, donc il suffit de changer l'adresse dans le registre vbr : c'est pratique
Citer : Posté le 03/08/2015 18:39 | #
Les explications du projet sont très claires, j'ai pratiquement tout compris alors qu'avant c'était un peu flou
Je me rend compte de la complexité du projet. Tu dois être un "as" de l'assembleur maintenant.
Encore une question : La ROM n'est pas protégée ?
Ajouté le 03/08/2015 à 18:40 :
Dommage de ne pas détenir une SH3 pour les tests
Citer : Posté le 05/08/2015 22:57 | #
Sans trop me mouiller, je dirais que la ROM est protégée : on ne peut pas écrire sur l'OS (et heureusement d'ailleurs), mais étant donné que ce dernier est presque entièrement chargé en RAM, on peut modifier cette dernière sans altérer le système. C'est d'ailleurs comme ça que fonctionne FiXos (changement d'OS directement dans la RAM, rien n'est touché dans la ROM).
Sinon, excellent boulot Lephe, tu redonnes une seconde vie aux caltos monochrome.
Citer : Posté le 06/08/2015 08:31 | #
Tu est entrain de dire que FiXos ne change pas l'OS présent dans la ROM mais change seulement ce qui est dans la RAM ? Pourquoi ne pas ne pas avoir les deux en même temps
@lephé : super boulot
Citer : Posté le 06/08/2015 14:38 | #
Tu est entrain de dire que FiXos ne change pas l'OS présent dans la ROM mais change seulement ce qui est dans la RAM ? Pourquoi ne pas ne pas avoir les deux en même temps
Parce que FiXos n'est pas forcément stable et nécessite un restart pour redémarrer la calto. Et puis le bootloader ne s'exécute pas au lancement de la machine. Donc bon, on évite de trop toucher à l'OS de Casio si on veut garder sa caltoche
Citer : Posté le 18/08/2015 21:17 | #
Les explications du projet sont très claires, j'ai pratiquement tout compris alors qu'avant c'était un peu flou
Je me rend compte de la complexité du projet. Tu dois être un "as" de l'assembleur maintenant.
Oui, c'est que pour SH3, mais le port sur SH4 ne nécessite que le timer, que j'aurai avec la doc... pour l'instant je ne sais pas quel est le MPU : les sites casio donnent le sh7305 mais il n'existe pas (?) et aucun de ceux cités dans la bible de teamfx n'est le bon.
En asm, je commence à m'y connaître, ouais...
Encore une question : La ROM n'est pas protégée ?
Si. Déjà, il faut que l'adresse pointe dans la mémoire physique, et l'accès n'est pas évident. Basiquement, on peut lire dans la rom de la même manière que dans la ram. Pour l'écriture, ça varie en fonction des espaces (user P0 ou protected P1-P4) et de ce que le système autorise. De plus, je pense que l'écriture directe dans le système de fichier est réglementée par le système (enfin... je me comprends).
Si ça t'intéresse, lis la section 3 (MMU) de la doc du sh7705, tu y trouveras des infos sur les espaces et l'adressage en mémoire physique.
Dommage de ne pas détenir une SH3 pour les tests
Je fais de mon mieux pour le porter sur SH4 au plus vite !
Sinon, excellent boulot Lephe, tu redonnes une seconde vie aux caltos monochrome.
J'irai pas jusque-là mais ça fait plaisir de voir que ça fonctionne.
Photo en prime (désolé Darks, rien de nouveau pour toi) !
@lephé : super boulot
Il est commenté, mais bon faut connaître un peu aussi hein
Ajouté le 18/08/2015 à 21:18 :
Infos intéressantes sur l'avancement du projet :
Ce que j'ai fait d'intéressant pendant cette quinzaine :
- Character maps. Elles vont avec la fonction keyboard_char() qui renvoie le caractère associé à l'id de touche passé en paramètre en utilisant une character map, soit CHARMAP_FLAT (pression basique) soit CHARMAP_ALPHA (alpha activé). Par exemple, keyboard_char(KEY_7, CHARMAP_FLAT) = '7' et keyboard_char(KEY_7, CHARMAP_ALPHA) = 'M'. Cette implémentation est rapide et à vitesse (presque) constante donc n'hésitez pas à en abuser pour limiter les cascades de tests quand vous faites du user input !
- Une bonne valeur de gris. Enfin... ça dépend. Il s'agit 3200, 3700. Elle est assez propre (je ne trouve pas le léger clignotement gênant) et d'une très grande stabilité, sans le moindre clignotement ponctuel ni ligne de rafraîchissement ! Avec une palette assez large pour distinguer le gris foncé du noir er le gris clair du blanc, c'est à mon goût la meilleure que j'aie essayée. Cependant, l'effet quand on lance le moteur varie d'un coup sur l'autre et est souvent bien moche. En fait, ça ne fonctionne quasiment que quand je règle manuellement le moteur à 3200, 4300 avant de le redescendre à 3200, 3700. C'est très curieux... d'ici à ce que je comprenne le phénomène, le couple 3200, 4100 a un rendu très correct, qui, utilisé sur des petites images (tilesets) a un rendu très propre qui suffit à mon avis pour la plupart des applications !
- Une fonction de gestion plus poussée du clavier : getkey_opt(). Elle étend getkey() et vous pouvez la considérer comme l'équivalent de GetKeyWait(). Bon, juste que pour l'instant on ne peut pas mettre de délai. Voilà la liste des options disponibles, au moins il y en a des nouvelles qu'on ne pouvait pas réaliser avec fxlib !
- Getkey_NoOption : il faut bien que je cite toutes les valeurs de l'enum...
- Getkey_ReturnOnRelease : la fonction s'arrête aussi lorsqu'aucune touche n'est pressée (utile pour détecter les relâchements). La gestion des répétitions est conservée.
- Getkey_RepeatAllKeys : une fonctionnalité qui permet de répéter toutes les touches (je verrai plus tard pour les répéter individuellement).
- Getkey_AllowAllRepeats : ordinairement, seule une répétition sur quatre est autorisée (les répétitions sont trop rapides sinon), et parmi celles-ci les deux premières sont encores ignorées pour laisser un délai plus important la première fois. Cette option permet d'autoriser toutes les répétitions, et renvoie donc des évènements quatre fois plus vite que d'habitude, si vraiment vous avez besoin d'une sensibilité temporelle élevée.
Au passage, getkey() est un pur getkey_opt(0) bien tassé.
Citer : Posté le 18/08/2015 21:56 | #
Ayant vu le gris IRL, je peux vous dire que c'est encore mieux que sur la photo — qui présente deux gris quasi identique — pour un rendu vraiment sympa
Sinon, au niveau du clavier, je pense qu'il faudra un exemple, je te suis de moins en moins x)
Citer : Posté le 18/08/2015 22:02 | #
Sinon, au niveau du clavier, je pense qu'il faudra un exemple, je te suis de moins en moins x)
→ Le timer vérifie régulièrement si une touche est pressée
→ Chaque fois qu'une touche est pressée, ça génère une répétition de fréquence f0 = fréquence du timer.
f0 est trop rapide pour un programme. Donc le moteur répète getkey() tous les f1 = f0 / 4.
→ Getkey() est répété tous les f1.
→ Additionnellement, les deux premiers f1 sont ignorés (le délai avant la première répétition de la touche est plus grand normalement).
GetKey_RepeatAllKeys permet de répéter toutes les touches, plus seulement les directionnelles, quelle que soit la fréquence de répétition de GetKey().
GetKey_AllowAllRepeats permet de répéter GetKey() tous les f0, au lieu de f1, quelles que soient les touches répétées.
Ajouté le 18/08/2015 à 22:03 :
Ah oui, j'ai ajouté un paragraphe « en bref » au début, parce que ça fait beaucoup à lire sinon. x)
Citer : Posté le 18/08/2015 22:10 | #
Je vois un peu mieux. Je ferai quand même des exemples d'applications propres
Ajouté le 18/08/2015 à 22:16 :
Je viens de relire la description, c'est vachement bien vulgarisé
Citer : Posté le 18/08/2015 22:16 | #
Je viens de relire la description, c'est vachement bien vulgarisé
Ah, merci !
Citer : Posté le 21/08/2015 12:55 | #
Raah ! J'ai tellement d'idées de jeux en ce moment mais je ne veut pas les commencer car j'arrête pas de me dire que ça serait 10 fois mieux avec les niveaux de gris
-> Pense tu qu'un programme normal avec des graphismes réalisés avec la fxlib (ou MonochromeLib) pourra facilement être modifié pour ajouter les niveaux de gris et la gestion des controls ?
En tous cas, Bravo
- Un pong multijoueur avec le cable 3pin
- Communication IR entre caltos (Arduino)
Citer : Posté le 21/08/2015 14:27 | #
Raah ! J'ai tellement d'idées de jeux en ce moment mais je ne veut pas les commencer car j'arrête pas de me dire que ça serait 10 fois mieux avec les niveaux de gris
N'hésite pas, le monochrome a aussi un certain charme
-> Pense tu qu'un programme normal avec des graphismes réalisés avec la fxlib (ou MonochromeLib) pourra facilement être modifié pour ajouter les niveaux de gris et la gestion des controls ?
Tout est différent avec cette lib (qui servira de base au fxSDK).
Pour le contrôles, il « suffira » de remplacer entre autres « GetKey(&key); » par « key = getkey(); » et les identifiants de touches, comme « KEY_CTRL_EXIT » par « KEY_EXIT ». Les touches plus complexes ne sont pas encore gérées, notamment avec SHIFT et ALPHA. Je pourrai implémenter les deux plus tard.
Pour le dessin, c'est plus difficile. De nombreuses fonctions existeront avec des paramètres similaires, que ce soit ML_line(), Bdisp_DrawLineVRAM() ou dline(), mais je ne pense pas que ma gestion des couleurs sera aussi poussée que celle de PLL -- enfin, pas pour tout de suite en tous cas. Les bitmaps seront un peu différents, il faudra s'adapter sur ce plan-là -- enfin, surtout les images en gris en fait.
Pour le reste, pas de trucs extraordinaires, c'est surtout l'API qui change et pas trop le principe. Ah, si : plus de Print() et autres de la famille de fxlib, mais la libfont que j'ai implémentée. J'ai quelques fonctions qui rendent exactement le même résultat donc pas de quoi s'en faire plus que ça -- juste 700-900 octets en plus dans le programme, et les caractères spéciaux malheureusement.
En tous cas, Bravo
Je pense pouvoir faire mieux, tant au niveau de la stabilité du gris que des graphismes en eux-mêmes
Citer : Posté le 21/08/2015 17:34 | #
Au niveau des bitmaps, tu comptes les stocker directement en 2-bits c'est ça ? Ce qui laisse quand même une seule déclaration par bitmap. (Ce qui n'est pas le cas actuellement avec le moteur de Kucalc)
Ou alors (vu que le moteur sera presque une exclusivité du fxSDK
Citer : Posté le 21/08/2015 17:43 | #
C'est vrai tu gères comment les bitmaps ?
Tu fais 4 vram classiques, une pour chaque couleur, ou tu fais une vram où un pixel c'est codé sur deux bits ?
Citer : Posté le 21/08/2015 18:01 | #
Pour du 4 niveau de gris il faut que 2 images