http://www.planet-casio.com Programmes Casio, Jeux, Cours pour Calculatrices Casio fr-FR https://www.planet-casio.com/images/logo.gif http://www.planet-casio.com 55 50 Programmes Casio, Jeux, Cours pour Calculatrices Casio. Tue, 01 Apr 2025 03:46:04 GMT Tue, 01 Apr 2025 03:46:04 GMT contact@planet-casio.com (Planet Casio) contact@planet-casio.com (Planet Casio) 5 https://www.planet-casio.com/Fr/forums/topic18681--.html As my first python program I decided to make Sudoku. https://i.imgur.com/i5zmGs9.jpeg Here's the link It's really not bad though IMHO- I'm a bit of a perfectionist. It has a nice interface and even a custom small number font. The code is probably not very pythonic or optimized though. I also had to keep it under 300 lines so I could use the Casio python script editor. Of course this would not have been possible without ExtraPython, so thank you to everyone involved in that! The game can only run on the ExtraPython add-in. Unfortunately there are no screenshots as I don't know how to build/run the emulator. Maybe someone else can take a few ss/gif? For this version there are no save states, 4 difficulties, and a limited amount of games available. Lephe tells me support for file read/write will hopefully be added to EP in the near future, and then I can add save states and 100s of games. Also possibly on the agenda for the future is a reveal/reveal all option. Let me know what you think, because I'm unsure if that's even a positive feature. If you have any other features requests/comments please let me know! Fri, 28 Mar 2025 02:54:20 +0100 https://www.planet-casio.com/Fr/forums/topic18675--.html Hello les gens ! ^^ Pour simplifier le debugging de mes projets casio, j’ai conçu un flux de sortie graphique inspiré de std::cout, appelé casio::dout, et je vais vous le partager. J'ai aussi ajouté un équivalent de printf. Équivalent de std::cout pour C++ Il gère : -La composition de flux avec << -Les retours à la ligne \n -Les fins de lignes avec casio::end -Les types string, int, float, etc. Exemple d’utilisation casio::dout(10, 20, C_WHITE) << "Valeur : " << 42 << casio::end; casio::dout(10, 60, C_WHITE) << "Pi ~ " << 3.14159f << "\nApproximatif" << casio::end; Comment ça marche ? Le système repose sur une classe DoutStream qui encapsule : -Les coordonnées (x, y) initiales -La couleur du texte -Un curseur de position mis à jour dynamiquement Le texte est découpé ligne par ligne, chaque mot est affiché avec dtext(), et les sauts de ligne sont simulés en ajustant les coordonnées via dsize(). Intégration Incluez simplement le fichier dout.hpp dans votre projet, et utilisez casio::dout() comme un flux standard. Code : #ifndef DOUSTREAM_HPP #define DOUSTREAM_HPP #include <gint/gint.h> #include <gint/display.h> #include <string> #include <sstream> #include <iostream> namespace casio { struct DoutEnd {}; inline DoutEnd end; class DoutStream { public: DoutStream(int x, int y, int color) : startX(x), curX(x), curY(y), color(color) {} template<typename T> DoutStream& operator<<(const T& value) { std::ostringstream oss; oss << value; processText(oss.str()); return *this; } DoutStream& operator<<(DoutEnd) { // Force une nouvelle ligne newline(); return *this; } private: int startX; int curX; int curY; int color; void processText(const std::string& text) { std::string line; for (char ch : text) { if (ch == '\n') { if (!line.empty()) draw(line); newline(); line.clear(); } else { line += ch; } } if (!line.empty()) draw(line); } void draw(const std::string& text) { dtext(curX, curY, color, text.c_str()); int w = 0, h = 0; dsize(text.c_str(), dfont_default(), &w, &h); curX += w; // Avancer horizontalement } void newline() { curX = startX; int h = 0; dsize("A", dfont_default(), nullptr, &h); // Hauteur de ligne curY += h + 1; } }; // Interface comme std::cout struct dout_creator { DoutStream operator()(int x, int y, int color) { return DoutStream(x, y, color); } }; inline dout_creator dout; inline void formatFloat(float val, char* out) { int sign = val < 0 ? -1 : 1; val = val < 0 ? -val : val; int int_part = static_cast<int>(val); int dec_part = static_cast<int>((val - int_part) * 1000 + 0.5f); // arrondi sprintf(out, "%s%d.%03d", (sign < 0 ? "-" : ""), int_part, dec_part); } inline DoutStream& operator<<(casio::DoutStream& out, float val) { char buf[32]; formatFloat(val, buf); return out << buf; } inline DoutStream& operator<<(casio::DoutStream& out, double val) { char buf[32]; formatFloat(static_cast<float>(val), buf); return out << buf; } } #endif Équivalent de printf pour C dprint est une réimplémentation simplifiée de printf Ce n’est pas un printf complet : -Pas de gestion des drapeaux (-, +, 0, etc.) -Pas d’alignement ou largeur (%5d, %05d, etc.) -Pas de support Unicode ou internationalisation Fonctionnalités prises en charge -Position (x, y) initiale personnalisable -Couleur personnalisée via int color -Gestion des \n comme retour à la ligne visuel -Reconnaissance et rendu des formats : ▬► %d / %i → int ▬► %u / %lu / %ld → unsigned int, long, unsigned long ▬► %zu → size_t ▬► %f / %.Nf → float ou double avec précision personnalisée ▬► %x → hexadécimal (minuscule) ▬► %p → pointeur ▬► %s → chaîne de caractères ▬► %b → booléen (true/false) ▬► %% → pour afficher un % (Le format %b n’existe pas dans printf, mais dprint le supporte) Exemple d’utilisation dprint(10, 10, C_WHITE, "Bonjour\ntout le monde !"); dprint(10, 30, C_WHITE, "Nom: %s Score: %d", "Alice", 42); dprint(10, 50, C_WHITE, "Pi ≈ %.3f", 3.14159f); dprint(10, 70, C_WHITE, "Taille: %zu octets", (size_t)512); dprint(10, 90, C_WHITE, "État: %b", true); dprint(10, 110, C_WHITE, "Adresse: %p", (void*)0x12345678); dprint(10, 130, C_WHITE, "Hex: %x", 255); dprint(10, 150, C_WHITE, "Progression: 100%%"); Code : #ifndef DPRINT_H #define DPRINT_H #include <gint/gint.h> #include <gint/display.h> #include <stdarg.h> #include <stdio.h> #include <string.h> #include <math.h> inline void formatFloat(float val, char* out, int precision) { int sign = val < 0 ? -1 : 1; val = val < 0 ? -val : val; int int_part = (int)val; int dec_part = (int)((val - int_part) * pow(10,precision) + 0.5f); // arrondi sprintf(out, "%s%d.%03d", (sign < 0 ? "-" : ""), int_part, dec_part); } void dprint(int x, int y, int color, const char* fmt, ...) { char buffer[256] = {0}; int cx = x; int cy = y; va_list args; va_start(args, fmt); while (*fmt) { if (*fmt == '%') { fmt++; int precision = -1; if (*fmt == '.') { fmt++; precision = 0; while (*fmt >= '0' && *fmt <= '9') { precision = precision * 10 + (*fmt - '0'); fmt++; } } char temp[64] = {0}; switch (*fmt) { case 'd': case 'i': sprintf(temp, "%d", va_arg(args, int)); break; case 'u': sprintf(temp, "%u", va_arg(args, unsigned int)); break; case 'x': sprintf(temp, "%x", va_arg(args, unsigned int)); break; case 'l': fmt++; if (*fmt == 'd') sprintf(temp, "%ld", va_arg(args, long)); else if (*fmt == 'u') sprintf(temp, "%lu", va_arg(args, unsigned long)); break; case 'z': fmt++; if (*fmt == 'u') sprintf(temp, "%zu", va_arg(args, size_t)); break; case 'f': { double f = va_arg(args, double); if (precision == -1) precision = 3; formatFloat(f, temp, precision); break; } case 's': snprintf(temp, sizeof(temp), "%s", va_arg(args, char*)); break; case 'p': sprintf(temp, "%p", va_arg(args, void*)); break; case 'b': snprintf(temp, sizeof(temp), "%s", va_arg(args, int) ? "true" : "false"); break; case 'c': snprintf(temp, sizeof(temp), "%c", va_arg(args, int)); break; case '%': strcpy(temp, "%"); break; default: snprintf(temp, sizeof(temp), "%%%c", *fmt); // Unknown format break; } dtext(cx, cy, color, temp); int w = 0, h = 0; dsize(temp, dfont_default(), &w, &h); cx += w; } else if (*fmt == '\n') { int h; dsize("A", dfont_default(), NULL, &h); cx = x; cy += h; } else { buffer[0] = *fmt; buffer[1] = '\0'; dtext(cx, cy, color, buffer); int w = 0, h = 0; dsize(buffer, dfont_default(), &w, &h); cx += w; } fmt++; } va_end(args); } #endif Sun, 23 Mar 2025 19:06:51 +0100 https://www.planet-casio.com/Fr/forums/topic18645--.html Bonjour, j'aimerais vous présenter une idée de programmer des jeux game boy avec gb studio. Je mettrais ici tous les jeux que j' aurais créés et si vous voulez en rajouter, dite le moi. ( gb studio est installable sur Windows, Linux et MacOS ) Fri, 28 Feb 2025 15:29:31 +0100 https://www.planet-casio.com/Fr/forums/topic18627--.html Hello, bon, s'ouvre désormais devant nous un vaste chantier de conversion des addins Prizm/Graph 90+E (les fx-CG10/20/50) vers la nouvelle plateforme Graph Math+ (fx-CG100). Comme vous avez pu voir par ailleurs, tout ne fonctionne pas direct out-of-the-box, et dans un certain nombre de cas, il va falloir mettre les mains dans le cambouis pour convertir les addins pour qu'ils tournent vers cette nouvelle machine. Je crée donc ce fil pour collecter et partager l'expérience de conversion, avec les succès mais aussi les galères afin de rapidement acquérir de l'expérience et partager dans la communauté. Idéalement le but est que ça communique. Mon, 10 Feb 2025 08:56:57 +0100 https://www.planet-casio.com/Fr/forums/topic18615--.html Suite à l'annonce que je contribuerai à la compabilitées des add-ins, je poste ce topic oû je (et n'importe qui autre voulant aider) posterai en commentaire la page de l'add in essayé avec en FJ les fichiers néscessaire (fichier pour SH4 ou pour G35E ii) Si quelqu'un d'autre que moi même veut aider, feel free (ouais, je ne sais pas parler français) de poster aussi si l'add-in essayé est compatible avec les SH4 avec le SH4 compability tool et/ou compatible pour Graph 35+E2 avec le patch binaire de Lephe'. Voilà tous de moi, je commence tout de suite... Pas de temps à perdre Sun, 26 Jan 2025 19:26:32 +0100 https://www.planet-casio.com/Fr/forums/topic18598--.html Bonjour à tous, voici un jeu que je programme en ce moment. C'est un smash bros avec les personnages de brawl stars (d'ou le nom smash brawl). Les seules aides dont j'aurai besoin, ce serait des images en 20*20 des brawlers (personnages de brawl stars) de profile Le jeu est sur C.Basic. Systeme Nombre brawlers Menus Graphismes Mon, 20 Jan 2025 23:49:42 +0100 https://www.planet-casio.com/Fr/forums/topic18583--.html Dans le topic Les projets de Planète Casio pour 2025 Sabercat a relancé l'idée d'avoir des bons outils de programmation on-calc (en plus de la compatibilité 35+E II mais ça ça ira dans un autre topic peut-être). Je liste ici les messages de cette discussion avec un résumé. Messages principaux : #198728, #198735, #198761, #198763, #198767, #198773, #198774, #198775, #198777, #198786, #198788 Ce qu'on pourrait viser comme langages : Python : ok, PythonExtra LuaFX : à porter Malical : à porter — y a-t-il de la demande ? Quelque chose pour coder des add-ins (C ? Autre ?) Basic : il y a déjà C.Basic (intégration sans doute impossible) Ce qu'on peut viser comme éditeur : A priori plutôt un éditeur séparé plutôt qu'un éditeur embarqué dans chaque appli Kiwi Text : mais copyright, pas de sources, apparemment pas complètement stable Micropy : existe déjà et marche, toutefois basé sur le PrizmSDK, et le support langage reste à coder Nouveau programme à base de gint + JustUI comme PythonExtra ou text-viewer Sabercat a mentionné qu'il serait bien de pouvoir coder des add-ins sur la calto. Je suis d'accord. Par contre, avoir un compilateur + linker sur la calto c'est trèèès ambitieux et porter les outils GNU c'est pas possible. Personnellement, je pense qu'il serait plus intelligent de coder des add-ins sur la calto dans un autre langage que le C. Je sais pas ce que vous en pensez... Fri, 10 Jan 2025 13:58:58 +0100 https://www.planet-casio.com/Fr/forums/topic18554--.html Mon project Bonjour à tous ! Cela fait litéralement 10 ans que je n'ai pas ouvert ce site ! C'est un plaisir de revenir ! La dernière fois j'étais au lycée et participais au concours des 10 ans du site avec CasioCraft, un petit terraria like. Je suis passionné par la programmation sur systèmes à ressources limités et récemment je me suis repris d'intérêt pour ma Casio 35+ et je compte reprendre CasioCraft, toujours en basic vanilla, pas d'overclocking. Dans la liste de ce que j'aimerai faire : - affichage dense : 32x12 cases, 3x3 pixels par bloc avec 1 pixel d'écart entre les bloc - au moins 16 blocs distincts - toute combinaison de 3x3 pixels affichable pour un bloc - "texture pack" modifiable - système de visibilité : les cases qui n'ont aucun coté en contact avec de l'air sont cachées - chargement d'écran "rapide" : si possible en moins de 10s (mon premier CasioCraft pouvait prendre entre 20 et 30s) - système d'inventaire "avancé" : barre active, inventaire, craft, coffre, loot... - monde "vaste" : je vise un minimum de 128x64 ou un système dynamique par chunk qui permettrait des mondes de forme arbitraire - génération "intéressante" : j'aimerai expérimenté avec des bruits à plusieurs octaves, probablement avec une base de perlin modifié, mais il faut alors s'attendre à une génération initiale de la map de plusieurs minutes Précision pour l'affichage, une fois un écran chargé, seul le joueur et les blocs cassés/posés seront mis à jour pour un rendu intéractif. Mais le joueur pourra recentrer l'écran sur lui à volonté et c'est ce chargement qui devrait durer une dizaine de secondes. Je m'excuse par avance, cet article va être long et technique ! Il nécessite de bonne connaissance en binaire et en multiplication matricielle. J'espère qu'il sera intéressant à lire et potentiellement inspirant. Pour le moment je me concentre sur le stockage et l'affichage. Pour stocker de vaste monde sans exploser la capacité limité de mémoire de la 35+ il parait évident que je vais devoir compresser la donnée. Pour afficher un écran rapidement et "jouer" dedans il est fort probable que j'utilise une autre représentation décompressée. Pour avoir un temps de chargement limité la transformation entre les 2 représentations doit être très efficace. Si vous avez des idées géniales je suis preneur ! Stockage De mon côté j'explore la piste du "binary packing". Tous les nombres (entiers ou floatants non imaginaires) de la 35+ sont représentés sur 12 octets (96 bits). Je n'ai pas fait de recherche sur la représentation interne de ces nombres, mais empiriquement les entiers de 0 à ~2^33 (0b100100010000001011111000111111111 pour être exacte) sont considérés "non floatants" et supportent donc les opérations "strictement entières" comme MOD. Malgré cela, les entiers se comportent comme attendu jusqu'à 2^43 environ, passé ce point, les additions et soustractions perdent en précision et les derniers bits peuvent être tronqués. Etonnemment, d'autres opérations marchent correctement jusqu'à 2^47 environ. J'imagine que c'est un format propriaitaire avec 48 bits de mantisse et des bits de metadata pour des optimisations spécifiques à la casio. En tout cas ce n'est pas IEEE 754. Malheureusement la 35+ n'a pas d'opérations binaires (and/or/xor/shift) sur les nombres, pour extraire le Nième bit d'un nombre X il faut donc utiliser des opérations algébriques : - MOD(X int÷ 2^N, 2) : fonctionne jusqu'à 2^33 environ - int(2 frac(X÷2^(N+1)) : fonctionne jusqu'à 2^47 environ Si vous connaissez une méthode encore plus efficace pour packer et extraire des bits, je suis preneur ! 47 bits sur 96 ce n'est pas un très bon ratio. Je pense qu'un bloc peut être représenté par 5 bits : 4 pour le type (16 bloc différents) et 1 pour la visibilité (pour éviter de revisiter ses voisins à chaque chargement). Une première approche serait de packer 6 ou 9 blocs dans un seul entier utilisant 30 ou 45 bits (compatible avec la première ou deuxième méthode de décodage respectivement). Je peux ensuite stocker ses nombres dans une matrice (compressant les lignes ou les colonnes), ou dans une liste en utilisant la deuxième méthode : 128x64/9 ≈ 911 < 999. De façon consécutive ou désordonné par chunk (avec une autre table de metadata pour les retrouver). Une compression RLE (Run Length Encoding) pourrait grandement diviser la mémoire nécessaire, au prix d'une décompression beaucoup plus longue. Decompression J'avoue que cette partie me parait particulièrement complexe. Pour ce qui suit, considérons que le blocs sont "simplement packés" et stockés dans une matrice compressée par ligne. Si un entier stock 6 blocs, 7 entiers doivent être récupérés pour former une ligne de 32 blocs (6x7 = 42, 10 blocs sont inutilement décodés). De même pour : - 9 blocs par entier : 5 entiers à récupérer, 13 blocs décodés inutilement - 8 blocs par entier : 5 entiers à récupérer, 8 blocs décodés inutilement Ce n'est pas optimal pour le stockage, mais 8 blocs par entier semble un bon compromis. J'utiliserai donc cette valeur à partir de maintenant, mais rapelez vous que rien n'est définitif sur la façon dont la donnée est compressée et stockée. Je ne me rapelé pas que le basic casio était aussi lent, simplement itérer sur chaque bloc d'un écran prend 7s ! For 1→J To 12 // Y For 1→I To 5 // X Mat[I, J]→C // entier compressé For 1→K To 8 // sub X Int(32Frac(C÷32^K))→D // bloc décompressé Next Next C'est bien entendu sans compter le temps de traitement de chaque bloc, qui consiste certainement à : - stocker sa valeur dans une matrice décompressée (ou un format optimisé pour l'affichage) - tester/séparer sa visibilité de son type - afficher le bloc en fonction de sa visibilité et de son type Une méthode potentiellement plus efficace (plus rapide, mais peut être plus dur à utiliser ensuite) consiste à utiliser les capacités vectorielles de la casio. Voici le code (une explication suit) : Seq(1÷32^N,N,1,8,1)→List 1 Trn List→Mat(1)→Mat B {60,8}→Dim Mat C // matrice décompressée, chaque cellule représente un bloc, au lieu d'être 12x32, elle contient les blocs inutiles 12x40 = 12x5x8 = 60x8 60→Dim List 1 // liste de tous les entiers compressés d'un écran For 1→J To 12 // Y For 1→I To 5 // X Mat A[I, J]→List 1[12I+J-12] Next Next // Décompression vectorielle ! Int(32Frac List→Mat(1)Mat B)→Mat C Ce code prend seulement 2s ! Mais le résultat est plus difficilement exploitable, c'est une matrice de 60x8, pratique pour tester les collisions, casser/placer des blocs (avec un simple changement d'index 32x12→60x8), mais je ne vois pas de façon efficace pour faire l'affichage. Rapide explication de cet algo avec une version simplifiée du problème, considérons que List 1 contiennent 3 nombres (A, B et C) et que l'on veut obtenir leur représentation binaire sur 3 bits. La matrice B contient l'inverse des puissances de 2 de 1 à 3 (chaque entier de List 1 contient 3 "groupes" de 1 bit). List 1 = {A, B, C} List→Mat(1)Mat B = ┌ ┐ ┌ ┐ │A│ │A/8, A/4, A/2│ │B│[1/8, 1/4, 1/2] = │B/8, B/4, B/2│ │C│ │C/8, C/4, C/2│ └ ┘ └ ┘ Il ne reste plus qu'à appliquer la formule Int(2Frac(X)) à chaque élément, ce que la casio permet de faire "d'un coup" : List 1 = {1, 3, 6} ┌ ┐ │0, 0, 1│ Int(2Frac(List→Mat(1)Mat B)) = │0, 1, 1│ │1, 0, 1│ └ ┘ Dans l'algo de décompression List 1 contient tous les blocs à décompresser, Mat B les puissance de 32 de 1 à 8 (entier contient 8 groupes de 5 bits). Affichage Mon premier CasioCraft utilisait une commande Text pour chaque bloc, ce qui n'est pas efficace du tout. Une deuxième version (non publiée) utilisait un Text par ligne (en utilisant les String), ce qui est beaucoup plus efficace du moment que l'on peut construire les Strings rapidement (ce qui n'est pas chose facile suivant l'algo de décompression utilisé). Un désavantage de cette technique est que les blocs affichables sont restreints aux caractères affichable par Text. La palette est toute fois relativement étoffée mais loin de pouvoir représenter toutes les combinaisons de 3x3 pixels. Une deuxième approche est le DrawStat. Encore faut-il trouver une façon efficace de dessiner 32x12 cases de 3x3 pixels où chaque case peut avoir un paterne différent. Je pense avoir trouvé une façon intéressante, mais difficile à exploiter. Elle utilise 5 listes : - List 1 : coordonnées X des points "actifs" - List 2 : coordonnées Y des points "actifs" - List 3 : coordonnées complexes X+iY de tous les blocs visibles (non air et non cachés) - List 4 : liste des "bitmap" de chaque bloc visible (un entier de 0 à 2^9-1) - List 5 : liste temporaire Voici un code pour initialiser les listes avec des paternes aléatoire, juste pour tester : // je remplis seulement 10x12 blocs, il est peu probable que les 32x12 blocs soient tous visibles en même temps 0→K For 0→J To 12 For 0→I To 10 K+1→K 4I+4Ji→List 3 // coordonnées X+Yi RanInt#(0,511)→List 4 // random bitmap Next Next Et le code pour dessiner : S-Grph1 DrawOn,Scatter,List 1,List 2,Dot BG-Pict 1 0→K // itère les 3x3 pixels de chaque bloc For 0→J To 2 For 0→I To 2 K+1→K // extrait le Kième bit de chaque bitmap (0 ou 1) et multiplie leur position Int(2Frac(List 4÷2^K))List 3→List 5 ReP List 5→List 1 // coordonnées X ImP List 5→List 2 // coordonnées Y ViewWindow -I,126-I,1,-J,62-J,1 // 127x63 pixels, origine décallée par I et J DrawStat StoPict 1 Next Next Ce code dessine une liste de blocs en 9 DrawStat en suivant une liste de bitmap. Pour toute itération (I, J) List 5 contient une liste de cooronnées : - 0+0i si le bloc correspondant n'a pas de pixel dans sa bitmap à la position [I, J] - X+Yi si non, où X et Y sont les coordonnées du bloc correspondant Chaque DrawStat dessine donc tous les pixels [I, J] de tous les blocs qui ont ce pixel dans leur bitmap, et un pixel en (0, 0) pour tous les blocs qui n'ont pas le pixel [I, J] dans leur bitmap. Cette méthode prend 10s pour afficher 120 blocs (et grandit linéairement avec le nombre de blocs à afficher). Ce qui n'est pas trop mal. Encore faudrait-il avoir un moyen efficace de décompresser le format de stockage dans ce format spécifique. A noter que le format compressé proposé est suffisamment simple pour permettre les accessions nécessaires pour les tests de collisions et casser/poser des blocs. Décompressé "un écran" dans un format "à plat" n'est pas strictement nécessaire. La seule décompression nécessaire est vers un format optimisé pour l'affichage. J'ai fait quelques tests avec le super DrawStat/Graph(X,Y) mais aucun résultats conluants. Conclusion En résumé beaucoup d'ambition, des techniques intéressantes (je trouve), mais pas énormément de résultats. L'utilisation des capacités vectorielles de la casio me semble essentielle pour parvenir à des temps de chargement raisonable. Encore désolé pour le pavé ! Si vous avez des pistes, des informations sur le format binaire, des idées pour le stockage/decompression/dessin, ou des remarques je serais très content de les lire ! Fri, 27 Dec 2024 18:59:01 +0100 https://www.planet-casio.com/Fr/forums/topic18531--.html Bonjour, Ce qui suit est mon premier message ... Je viens tout juste de m'inscrire à ce site et, après avoir sorti ma calculatrice CASIO fx-9860G de son lieu de stockage et "d'oubli", tenté de créer un programme à l'intention d'une personne pas du tout versée en calculs et encore moins en programmation ... Cette programmation 'Basic' de CASIO, malgré ma grande expérience en programmation orientée plutôt en langage C (LabWindows) sur PC, se révèle assez déroutante et plutôt limitée en possibilités. Il faut dire que je viens tout juste de constater que sur ce modèle fx-9860G on ne peut pas traiter les chaînes de caractères ! L'entrée manuelle de données par la fonction 'Getkey' en testant le code associé à une touche du clavier n'est pas évidente du tout. Mon dernier problème se trouve être l'appel d'un 'sous-programme' à partir d'un programme principal : Je crois avoir compris qu'il faut utiliser 'Prog' et 'Return', mais où et comment ... Merci de bien vouloir m'aider à solutionner ces questions mais sans me demander de changer de modèle de calculatrice. Meilleures salutations. W. Fürst CH-1197 Prangins Suisse Sun, 01 Dec 2024 17:41:03 +0100 https://www.planet-casio.com/Fr/forums/topic18266--.html Duvet Duvet is a spreadsheet add-in for Casio fx-9860G or later (including Slim), both mono and color calculators, as an alternative to Casio's built in spreadsheet/S-SHT app. https://i.imgur.com/i7bKqkq.png Motivation The initial idea for writing a spreadsheet add-in came because, at the time, the Math+ didn't provide a spreadsheet app. I was also interested to see whether a spreadsheet could be made to be Turing-complete with a SET(column, row, value) formula. Additionally, S-SHT was very slow and I wondered if I could do better. However, Casio announced a spreadsheet for Math+ and other projects were more interesting, so it got shelved. The project was revived when I received my fx-CG50 and my CPC game entry would load, but could not be edited without a math error, despite working (albeit very slowly) on the fx-9750GIII and even working on the fx-9860G Slim. In order to get the game working on the fx-CG50, I had to delete over 500 cells. And, even then, it was still quite slow. I wanted my game to be playable on all calculators, so I challenged myself to write a spreadsheet add-in before CPC 31. Goals My goals for Duvet are: 1. Faster calculation than S-SHT. Duvet uses integer math, when possible, and the plan is to examine floating point results and return them back to integers, when possible. For example, 10 / 2 = 5.0, but 5.0 == 5, so it can remain an integer, and cos(0) = 1. Currently, Duvet calculates my CPC entry, a sheet containing around 1000 formula cells, in a fraction of a second, compared to approximately 7 seconds in S-SHT on an fx-9750GIII. Video from an earlier build (fx-9750GIII and S-SHT on the left, fx-9860G Slim and Duvet on the right): https://i.imgur.com/zJk7gSC.mp4 2. Provide a larger sheet area than S-SHT, using sparse cells. Currently, Duvet allows 26 columns (A-Z) and 2048 rows. 3. Be compliant with some subset of ODF types, operators and formulas. In particular, I want to allow formulas involving TEXT fields, which isn't possible in S-SHT. 4. Turing-completeness, by way of a SET(column,row,value) formula. 5. File import/export. Formats to be determined, but at least CSV import/export. 6. Best effort: due to spreadsheets often being used for financial calculations, I'd like to use decimal64 floats (or an equivalent) rather than using double. The decimal library I was planning on using (libdfp)) is not available for SuperH, and I need to investigate the feasibility of porting it. Notably, it is not a goal to perfectly replicate the UI or feature set of Casio's S-SHT. For example, the UI has already diverged slightly, the menus and key input are going to be different, and I don't currently plan on implementing graphing, regressions, list import/export, etc. Nor is it a goal to be 100% Open Document Format or OpenFormula compliant. However, I'll strive (best effort) for subset compliance as far as being able to export a LibreOffice sheet to CSV and have some subset of OpenFormula formulas, operators, and data types work without changes. Formulas All formulas are currently limited to 64-bit integer math: • ABS(integer) → integer • BITAND(integer,integer) → integer • BITLSHIFT(integer,integer) → integer • BITOR(integer,integer) → integer • BITRSHIFT(integer,integer) → integer • BITXOR(integer,integer) → integer • FALSE() → integer • IF(integer,integer,integer) → integer • ISEVEN(integer) → integer • ISODD(integer) → integer • MOD(integer,integer) → integer • NOT(integer) → integer • SIGN(integer) → integer • SUM(range) → integer • TRUE() → integer Formulas Planned This is just an initial list of formulas where integer math can be used; there will be more once I implement the NUMBER type and determine which TEXT operations are feasible: AND(range), AVERAGE(range), DELTA(a,b), FACT(integer), GCD(range), LCM(range), MAX(range), MIN(range), OR(range), POWER(integer,integer), PRODUCT(range), QUOTIENT(integer,integer), RANDBETWEEN(integer,integer), SET(column,row,value), XOR(range) Operators Listed in order of precedence, highest first: • (integer) → integer • -integer → integer, +integer → integer • integer^integer → integer • integer*integer → integer, integer/integer → integer • integer+integer → integer, integer-integer → integer • integer=integer → integer, integer<>integer → integer, integer<integer → integer, integer<=integer → integer, integer>integer → integer, integer>=integer → integer Limitations Currently Duvet is extremely limited. It can play my CPC #31 entry, but that's about it: • Cannot create new sheets. • Sheets cannot be edited, except for cells containing integers (and also 64-bit integers cannot currently be edited). • Cells cannot be created, deleted, edited to become empty, copied, moved, etc. • Only loads and saves spreadsheets in a proprietary format. • Floating point math is not available (needed for Video Poker) • A `Ran#` substitute is not available (also needed for Video Poker) Name The name is meant to be silly. In British English, a duvet (or "duvet cover" here in USA) is a comforter, often used instead of a bedsheet ("sheet"). So, the name represents the idea of Duvet replacing S-SHT. And the name also appeals to me because it's a word common to both French and English. Source Code https://git.planet-casio.com/calamari/Duvet Fri, 25 Oct 2024 19:38:25 +0200