Visiteurs :
Si vous souhaitez soumettre un logiciel veuillez prendre contact avec un administrateur seuls à pouvoir ajouter des logiciels par mesure de sécurité.
Le LuaFX est un langage de programmation à mi-chemin entre le Basic et le C et offre de bonnes performances, supérieures au Basic et au MLC ! Les programmes se présentent sous forme d'addins à transférer sur la calculatrice Casio.
Le LuaFX est compatible avec les Graph 75/85/95 (SD) et 100(+) grâce à un formidable travail de Vebveb et de la communauté.
Mise à jour du 9/09/12 :
. possibilité de chronométrer, soit en tics ( 20 ms sur g100 et 1/64e de seconde sur g85), soit en temps réel.
. ajout de setmetatable et getmetatable des fonctions du package lua standard
. Gain de mémoire pour les programmes sur g85 (jusqu'à 38000 octets de place pour l'éxécution)
. Correction de la documentation
. Gris plus fiable sur g85
Mise à jour du 24/05/12 :
- pour graph85:
Il marche maintenant avec EDIT, et le contraste devrait être meilleur en mode gris.
- Pour AFX:
Correction d'un bug lorsque l'on traçait un rectangle en dehors de l'écran. Commentaires :
Est-ce qu'il y a encore des graph100 vendues, ou des gens qui programment dessus?
Est-ce que le code de gestion du gris pour g85 a été enfin fait proprement? C'était vraiment le cauchemar lors de la programmation de LuaFX.
Eventuellement, il serait temps de discuter ce qu'il y a de bien/pas bien dans l'API, et faire une refonte du projet pour une version graph85 avec beaucoup plus de fonctions haut niveaux et sans la compatibilité graph100.
Oh, un revenant ! Oui, il y a toujours des Graph 100+ vendues et achetées.
De temps en temps, un membre se risque à apprendre le LuaFX. Avec le nouvel OS 2.04 sorti récemment, je crois que ça provoque ponctuellement de nouvelles incompatibilités. Rapproche-toi de Dark Storm et de Lephenixnoir, et peut-être Ziqumu aussi, quoiqu'il soit moins actif ses derniers jours (sans doute les examens).
@Vebveb : Je suis content qu'il y ait un revenant, j'espère jusque que d'autres fonction vont voir le jour et j'espère que ça ne te dérange pas si j'ai mis ton dossier (fort intéressant )du lua sur CUW
La but initial du Lua sur graph100 était d'avoir un langage rapide, sans les défauts du MLC ou du BASIC, et que les programmes soient beaucoup plus simples à installer.
Il fallait faire avec les limitations des éxécutables sur graph100, et les fonctions étaient bas niveau, ce qui en fait un langage plus rapide que le Basic et le MLC, mais sans plus. Et beaucoup plus lent que le C.
Ensuite le portage sur graph85 était dans le but d'avoir des programmes compatibles.
Si on se restreind à la graph85, on n'a pas les limitations de l'exécutable sur graph100, et donc on peut programmer des fonctions de plus haut niveau, qui permetteront d'avoir une meilleur performance et un langage plus simple.
Ceci dis, c'est hors de question pour moi de programmer quoi que ce soit sur graph85 si le code de gestion des interruptions (pour le gris)n'est pas fait correctement. La manière dont c'était fait était vraiment buguée.
Je sais que les niveaux de gris sont garantis 100% non compatibles SH4 ^^, mais en a-t-on les sources ?
Si on pouvait les travailler en C, on pourrait facilement les porter en Lua.
Le truc, c'est que je n'ai jamais vraiment touché aux niveaux de gris (à part pour faire quelques tests). Disons que les EBR, ça démotive un peu de se lancer dans un gros projet avec des niveaux de gris.
En ce qui me concerne, j'ai toujours utilisé Easy Greyscales pour les niveaux de gris, en resetant la calto après utilisation. Si j'ai bien compris, c'est les changements des buffer vidéo/vram par timers qui posent problème ? Personnellement, ça marchait bien, donc je ne m'en suis jamais vraiment préoccupé...
Y'a aussi le fait de devoir quitter de manière "forte" la calto qui pose problème ? Il faudrait voir au niveau de gray_quit si y'a pas moyen de rendre propre la sortie...
tAu passage, je ne pense pas que Louloux sera plus compétent que moi dans le domaine, mais on peut toujours lui poser la question
Le problème, c'est que l'on bouge le pointeur sur la table des interruptions pour qu'il exécute notre code.
Avant:
Si une interruption arrive, le code de dispatch est appelé. Il appelle le code approprié pour gérer l'interruption.
Après:
Un interruption arrive, le code de gestion du gris est appelé.
Le problème c'est que si un interruption clavier ou autre arrive, on va éxécuter du code pour le gris, au lieu d'appeler du code casio pour gérer cette interruption. Cela cause des problèmes que l'interruption ne soit pas gérée.
Pour gérer le gris correctement, il faudrait écrire en assembleur un code de dispatch, qui redirigerait vers le code de dispatch écrit par Casio, lorsque le numéro de l'interruption n'est pas celui que l'on utilise pour le gris.
J'avais trouvé à l'époque de la documentation sur le code de dispatch en question, mais je ne connaissait pas assez bien l'assembleur de la graph85... Il faudrait que quelqu'un se dévoue et se documente sur cet assembleur et écrive ce code de dispatch.
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
et j'espère que ça ne te dérange pas si j'ai mis ton dossier (fort intéressant 
