Squish It !! - un addin pour les écrabouiller tous !!
Posté le 23/11/2025 19:59
Hello,
voici donc venu le jour tant attendu de la divulgation de la version 1.10 de Squish It !!, après une première version 1.00 limitée en fonctionnalités, qui faisait plus preuve de PoC que de réelle sortie.
1/ Squish It !! ? Késako
Vous n'êtes certainement pas sans savoir que la Graph Math+ sortie à la rentrée dernière est très proche de la G90+E, mais présente un énorme désavantage par rapport à son aïeule : une mémoire flash disponible pour l'utilisateur qui a fondu comme neige au soleil, passant de 16Mo à seulement 4,5Mo. Pour le commun des mortels utilisateurs, cela ne pose pas de problème, mais pour les power users et les codeurs, dont je fais partie et qui ont toujours 10 000 addins qui traînent sur leur machine pour tester des trucs, 4,5Mo, c'est la misère vite fait, toujours obligé de virer des trucs pour en mettre d'autres. Bref, c'est bien lourd !!!
Donc il y a 2 semaines environ, je me suis motivé pour créer un addins permettant de compresser et décompresser des addins on-calc afin de virtuellement faire comme si la machine disposait de plus de mémoire de stockage.
Ayant travaillé sur la librairie de compression zlib lors de la conversion de la SDL pour machines casio, je savais qu'on pouvait obtenir de relativement bons niveaux de compression sur des fichiers de type addins (cf. ce fil : Zlib pour Casio fx/cg (développement et benchmark)). J'ai donc voulu pousser le concept et proposer un utilitaire permettant de faire facilement ces opérations de compression/décompression.
Voici donc la genèse de Squish It !!
Petite vidéo de la version 1.00 lors de la compression d'un addin de Casio (3DGraph)
2/ Comment fonctionne Squish It !!
Squish It !! fonctionne sur Graph Math+ et fxCG-100 uniquement**, en OS version 2.00 et jailbreakée avec la dernière version de MPM que vous trouverez ici sur la forge de Planète Casio (il est important d'avoir au moins la version reposant sur le commit permettant de voir les fichiers G3A après décompression).
Squish It !! propose une interface simple permettant de lister les addins non compressés (au format G3A) ainsi que les éventuels addins compressés au format propriétaire de Squish It !! (à savoir le format G3Z). Le logiciel permet de compresser les fichiers G3A en G3Z selon diverses méthodes et niveaux de compression: format de compression Zlib avec compression maximale (notée ZlibMax) format de compression Zlib avec vitesse maximale (notée ZlibFst) format de compression LZ4 (HC) avec compression HC level 9 (notée LZ4Max) format de compression LZ4 (HC) avec vitesse rapide HC level 3 (notée LZ4Fst)
Il suffit de sélectionner dans la partie droite de l'écran un G3A non compressé et de faire EXE ou OK pour lancer la compression avec la méthode sélectionnée (la méthode pouvant être changée via la touche PageUp, l'option en cours étant indiquée à l'écran). Puis la compression se fait avec de multiples validations internes afin de ne pas avoir de soucis (bien lire les messages en bas de l'application sous la zone bleue). La compression par défaut est réglée sur ZlibMax.
Inversement, si vous avez un addin compressé au format G3Z et que vous voulez l'utiliser, il vous suffit de le sélectionner dans la zone ad-hoc à droite et là encore de faire EXE ou OK pour lancer sa décompression. Squish It !! sait bien entendu reconnaître le format de compression qui avait été utilisé et proposer automatiquement la décompression qui va bien.
On passe de la colonne gauche (Addins G3A) à la colonne de droite (Archives G3Z) avec les flèches gauche (<-) et droite (->) ou les touches Page Précédente (|<-) et Page Suivante (->|).
** Note: le programme est fonctionnellement capable de fonctionner sur Graph 90+E ou Prizm (fxCG-10/20 et 50), mais l'OS ne tolère pas l'écriture d'un fichier G3A depuis un addin en cours de fonctionnement (en l'occurence Squish It !!). Hélas toute tentative d'écriture du G3A après décompression se traduit par un crash instantanné de la machine.
3/ C'est fiable, ce Squish It !! ?
De nombreux tests ont été réalisés sur cette version. 31 Addins différents (32 en réalité puisque qu'un test de survie** incluant SquishIt.G3A a été réalisé à chaque round) ont été passés et testés avant et après chacune des méthodes de compression et de décompression. Cela fait vraiment beaucoup de tests, 4x2x31 tests, à savoir 4 méthodes (a.k.a. algorithmes), compression puis décompression puis lancement de l'addins afin de vérifier l'absence d'erreur, sur 31 addins représentant au total plus de 10Mo de data. Cela fait partie des règles pour proposer un programme éprouvé et ne présentant pas de risque pour votre machine.
L'ensemble des tests a été conduit avec succès. Le détail de ceux-ci est donné dans les chapitres suivant visant l'analyse des performances.
** Note: une sécurité est prévue pour empêcher de compresser le programme Squish It !! et ainsi se retrouver bloqué sans possibilité de décompresser les autres addins ultérieurement. En cas de tentative, un message d'erreur apparaît dans la zone de message en bas de l'écran.
4/ Que peut on en attendre ?
Selon la méthode utilisée, on peut s'attendre en moyenne à des taux de compression allant de 50% à 60% (le G3Z une fois compressé fait de 40% à 50% de la taille du G3A initial). Bien entendu il y a une certaine variabilité des taux de compression d'un addin à l'autre, ceux ci pouvant s'étaler d'environ 25% (le G3Z fait 75% de la taille du G3A) à 80% (le G3Z fait alors seulement 20% de la taille du G3A).
Avant de donner le détail méthode par méthode, voici les résultats globaux sur les 31 addins (tailles allant de 75kB à 1,5MB) :
Méthode
Taille cumulée (en kB)
Taux de compression moyen
Addins fonctionnels
Temps Cumulé de Compression (en s)
Temps Cumulé de Décompression (en s)
Addins non compressés
10136,1
(0%)
31
(-)
(-)
ZLibMax
4192,2
58,6%
31
940
1859
ZLibFast
4480,1
55,80%
31
924
1935
LZ4Max
4865,9
51,99%
31
999
2024
LZ4Fast
4992,4
50,75%
31
1010
1921
Le résumé est donné au global par les trois graphiques suivants :
Tout d'abord la comparaison des tailles d'archive G3Z selon la tailles des addins G3A en entrée. On note que la taille avec la méthode ZLibMax est toujours la plus faible.
Vient ensuite la comparaison des temps de compression des addins G3A pour obtenir l'archive G3Z correspondante. Il est intéressant de noter que les méthodes "Fast" se débrouillent moins bien que leurs homologues "Max", ce qui peut paraître paradoxal, mais cela s'explique simplement par la métrique utilisée qui incorpore tout le process Compression + Ecriture de l'archive et le gain de temps lié à la compression par une méthode plus rapide set plus que consommé par le temps d'écriture plus long lié à une taille d'archive plus imposante. En bref, avec une mémoire flash très lente sur Casio, la performance est limitée par celle-ci. Là encore c'est l'algorithme ZLibMax qui s'en sort le mieux du fait des archives les plus compactes. Il est à noter quand même une assez grosse disparité d'un addin à l'autre. Notamment pour les gros addins supérieurs à 1Mo qui semblent s'en sortir mieux avec la ZLibFast.
Enfin, les temps de décompression, en fonction de la taille de l'addin G3A en sortie. Globalement tout le monde est aligné à quelques epsilons, avec une relation purement linéaire à la taille de sortie.
5/ Et si moi j'aime les chiffres ?
Et bien, Grand Seigneur, je te mets l'ensemble des données qui a permis de faire les benchmarks. Amuse toi bien mon Ami
N'hésitez pas à faire part de vos commentaires, questions, idées d'amélioration ainsi que des bugs éventuels (avec si possible une manière de le reproduire facilement pour le debogguer). Je prendrais avec plaisir vos idées.
Très joli boulot, super Les 4.5 Mo de la Math+ ça pique à fond en effet, donc c'est cool d'avoir l'option de compresser.
Je pense qu'il y a aussi un effort à faire côté gint pour générer moins de données pour les assets et/ou gratter du code, parce que le meilleur moyen d'avoir des petits fichiers est de mettre moins de trucs dedans.
Super figures du reste, on dirait presque un papier haha.
On se refait pas, c'est le chercheur qui a ses habitudes
Effectivement on voit que les addins avec beaucoup d'assets occupent beaucoup de place. Il y a vraiment moyen de gagner sur ce point.
Je vais aussi essayer de faire de la décompression en RAM à un moment, ce qui m'embête c'est de devoir isoler la décompression du header du G3A puis de mettre le code au bon endroit. Ou alors on peut peut être décompresser en RAM puis faire pointer le CPU vers l'adresse du début du code. Je ne connais pas assez. Cela permettrait aussi de gagner le temps de l'écriture sur la flash, car c'est vraiment une horreur.
D'ailleurs, est ce que cela ne permettrait pas de s'affranchir de la limite des 2Mo des addins ? Est-ce une limite de taille d'addins ou de code que peux "gérer" l'OS ?
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Pour la décompression en RAM, faut juste la coder dans mpm.bin avec le lanceur. Ce serait plus fluide et y'aurait pas besoin de l'étape supplémentaire de rentrer dans Squish It !! pour pouvoir lancer les add-ins.
Il n'y a pas de limite en théorie pour MPM mais en pratique quand j'ai essayé de monter la limite pour KhiCAS ça créait des bugs. Je crois savoir qu'il y a un problème avec la gestion du cache durant le chargement et c'est peut-être ça. Mais en théorie non pas de limite de taille sur la Math+ (ironique).
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
format de compression Zlib avec compression maximale (notée ZlibMax)
Citer : Posté le 24/11/2025 21:11 | #
Très joli boulot, super
Je pense qu'il y a aussi un effort à faire côté gint pour générer moins de données pour les assets et/ou gratter du code, parce que le meilleur moyen d'avoir des petits fichiers est de mettre moins de trucs dedans.
Super figures du reste, on dirait presque un papier haha.
Citer : Posté le 24/11/2025 21:44 | #
On se refait pas, c'est le chercheur qui a ses habitudes
Effectivement on voit que les addins avec beaucoup d'assets occupent beaucoup de place. Il y a vraiment moyen de gagner sur ce point.
Je vais aussi essayer de faire de la décompression en RAM à un moment, ce qui m'embête c'est de devoir isoler la décompression du header du G3A puis de mettre le code au bon endroit. Ou alors on peut peut être décompresser en RAM puis faire pointer le CPU vers l'adresse du début du code. Je ne connais pas assez. Cela permettrait aussi de gagner le temps de l'écriture sur la flash, car c'est vraiment une horreur.
D'ailleurs, est ce que cela ne permettrait pas de s'affranchir de la limite des 2Mo des addins ? Est-ce une limite de taille d'addins ou de code que peux "gérer" l'OS ?
Citer : Posté le 24/11/2025 21:58 | #
Pour la décompression en RAM, faut juste la coder dans mpm.bin avec le lanceur. Ce serait plus fluide et y'aurait pas besoin de l'étape supplémentaire de rentrer dans Squish It !! pour pouvoir lancer les add-ins.
Il n'y a pas de limite en théorie pour MPM mais en pratique quand j'ai essayé de monter la limite pour KhiCAS ça créait des bugs. Je crois savoir qu'il y a un problème avec la gestion du cache durant le chargement et c'est peut-être ça. Mais en théorie non pas de limite de taille sur la Math+ (ironique).