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 En ligne Administrateur Points: 24145 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.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, 4, 5, 6 ··· 10 ··· 20 ··· 30 ··· 40 ··· 50 ··· 60 ··· 70, 71, 72, 73 Suivante
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

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)
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Kirafi Hors ligne Membre Points: 2180 Défis: 10 Message

Citer : Posté le 26/07/2015 16:08 | #


C'est trop ça, notre Phénix pète des câbles depuis une heure avec son histoire de timer !
iPod
Pour des parties rapides
Jusqu'où pourras-tu aller dans ce jeu "partie rapide" qu'est Dextris (élu Jeu Du Mois)
Pourras-tu survivre plus de 20 secondes dans ce fameux tunnel appelé Graviton
Rebondis entre les murs en évitant les piques dans SpikeBird
Pourras-tu éviter de te faire écraser dans FallBlocs (élu Jeu Du Mois)
Autres
Franchement ils valent le coups
Deviens l'amiral de la marine dans SeaRush (jeu concours) (élu Jeu Du Mois)
La version 2048 tactile amélioré au plus haut point : 2048 Delux !
Pars à la recherche des morceaux d'étoile dans Lumyce (élu Jeu Du Mois)
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 26/07/2015 16:13 | #


Kirafi a écrit :
C'est trop ça, notre Phénix pète des câbles depuis une heure avec son histoire de timer !

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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

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?
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 En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 27/07/2015 21:25 | #


Dodormeur a écrit :
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

Dodormeur a écrit :
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 :
Lephenixnoir a écrit :
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.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2461 Défis: 24 Message

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 )
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 03/08/2015 09:48 | #


Ninestars a écrit :
D'accord ! En fait tu refais totalement le gestionnaire d'interruption !

Yep

Ninestars a écrit :
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
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Silaxe Hors ligne Membre Points: 809 Défis: 12 Message

Citer : Posté le 03/08/2015 18:39 | #


Si le projet vous intéresse, vous pouvez télécharger l'add-in de test et me dire s'il fonctionne bien sur votre machine, ou chercher des nouvelles valeurs pour le moteur de gris.
C'est juste pour SH3 j'imagine ?
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 .
Dark storm En ligne Labélisateur Points: 11631 Défis: 176 Message

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.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
-florian66- Hors ligne Ancien rédacteur Points: 2383 Défis: 20 Message

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 je voudrais quand tu auras fini avec ces interruptions que tu me passe ce code et si tu peux, me le commenter
In Arch, I trust ! And you ?
Dark storm En ligne Labélisateur Points: 11631 Défis: 176 Message

Citer : Posté le 06/08/2015 14:38 | #


-florian66- a écrit :
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
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 18/08/2015 21:17 | #


Silaxe a écrit :
Si le projet vous intéresse, vous pouvez télécharger l'add-in de test et me dire s'il fonctionne bien sur votre machine, ou chercher des nouvelles valeurs pour le moteur de gris.
C'est juste pour SH3 j'imagine ?
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...

Silaxe a écrit :
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.

Silaxe a écrit :
Dommage de ne pas détenir une SH3 pour les tests .

Je fais de mon mieux pour le porter sur SH4 au plus vite !

Dark storm a écrit :
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) ! (le tileset est home made)


-florian66- a écrit :
@lephé : super boulot je voudrais quand tu auras fini avec ces interruptions que tu me passe ce code et si tu peux, me le commenter

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é.

Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dark storm En ligne Labélisateur Points: 11631 Défis: 176 Message

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)
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 18/08/2015 22:02 | #


Dark storm a écrit :
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)
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dark storm En ligne Labélisateur Points: 11631 Défis: 176 Message

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é
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 18/08/2015 22:16 | #


Dark storm a écrit :
Je viens de relire la description, c'est vachement bien vulgarisé

Ah, merci ! Ça fait plaisir à entendre.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Theernest570 Hors ligne Membre Points: 64 Défis: 5 Message

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 ta photo postée plus haut me fait rêver !
Calto : Graph 35+(tweaké)
Projets
Fermer

- Un pong multijoueur avec le cable 3pin
- Communication IR entre caltos (Arduino)
Lephenixnoir En ligne Administrateur Points: 24145 Défis: 170 Message

Citer : Posté le 21/08/2015 14:27 | #


Theernest570 a écrit :
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

Theernest570 a écrit :
-> 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.

Theernest570 a écrit :
En tous cas, Bravo ta photo postée plus haut me fait rêver !

Je pense pouvoir faire mieux, tant au niveau de la stabilité du gris que des graphismes en eux-mêmes (là, j'essaie des tests sur un tileset 16x16 qui exploite complètement les quatres couleurs pour faire des textures : cependant, le gris manque à mon goût de stabilité pour permettre de l'exploiter tel quel).
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Dark storm En ligne Labélisateur Points: 11631 Défis: 176 Message

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 ) tu comptes utiliser les fichiers liés ?
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Ninestars Hors ligne Membre Points: 2461 Défis: 24 Message

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 ?
-florian66- Hors ligne Ancien rédacteur Points: 2383 Défis: 20 Message

Citer : Posté le 21/08/2015 18:01 | #


Pour du 4 niveau de gris il faut que 2 images
In Arch, I trust ! And you ?
Précédente 1, 2, 3, 4, 5, 6 ··· 10 ··· 20 ··· 30 ··· 40 ··· 50 ··· 60 ··· 70, 71, 72, 73 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 90 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