Pour utiliser l'add-in, vous avez besoin de mettre les fichiers :
badapple.g3a
et
ba.prm
dans le dossier racine
ATTENTION: Over/Under-clocker sa calculatrice avant de lancer l'addin peut entrainer des modifications a la vitesse de la vidéo!
Aussi: Vous devrez attendre la fin de la video(3 minutes environ) pour pouvoir sortir de l'addin(Pour cela, appuyez sur n'importe quelle touche)
Bon visionnage!
Aussi si vous voulez utiliser le programme pour une vidéo, envoyez moi un e-mail a et mentionnez moi avec le nom "DevHONK"
English description:
Bad Apple for FX-CG50
To use the add-in, you need to add those files:
badapple.g3a
and
ba.prm
in the root directory
WANING: Under/Over-clocking your calculator before running the addin might change the speed of the video!
Sidenote: You must wait until the end of the video in order to exit the addin(For that, press any key on your calculator)
Also, if you want to use the program in a video, email me @ and mention me with the name "DevHONK"
Bravo pour ton travail, l'animation est fluide et conforme à l'originale, c'est agréable.
Quelques petites remarques cependant :
– L'add-in est très lourd et met beaucoup de temps à être transféré (20 minutes chez moi). Je suppose cependant que le programme est déjà optimisé
– Les pixels restent relativement gros, mais ça c'est pas très grave. Je me demande quand une version en haute qualité sortira ahah.
– L'animation n'est pas centrée, ça serait plus joli qu'elle soit affichée au milieu de l'écran
Ta calto est craquée, il m'a fallu 5 secondes pour l'add-in et 1m55 pour le fichier de données.
À part ça ouais c'est vraiment fluide, et j'espère vraiment que quelqu'un va pousser pour voir jusqu'où on peut aller. Il y a eu plusieurs lecteurs vidéo avec le temps mais tous avaient de la marge sur l'exécution (AFAIK) donc on doit pouvoir faire mieux.
Après faut voir que BFile s'en mêle et ça c'est sûr que ça coûte assez cher. Il est possible que le chargement depuis la mémoire de stockage soit le plus compliqué. Comme c'est en lecture seule on pourrait soit utiliser les infos de Yatis pour chercher le fichier et l'ouvrir sans BFile (il suffit de suivre les fragments), soit faire comme DOOM et bourriner avec une signature pour chercher les fragments dans la ROM. Hmm...
Comme c'est en lecture seule on pourrait soit utiliser les infos de Yatis pour chercher le fichier et l'ouvrir sans BFile (il suffit de suivre les fragments)
mmmmm....je ne sais pas trop, pour l'instant j'ai seulement documenté l'ouverture des fichiers, je ne sais pas encore comment sont stockées les données. Mon hypothèse est que l'ouverture de fichier et la lecture sont longues uniquement parce que Casio dessine le rond en haut à droite. Dans mes tests, pour générer le callgraph, la primitive d'ouverture (Fugue uniquement) prenais ~5 secondes alors que la fonction de dessins (Casio) prenais ~3 secondes, soit un bon 30% du temps).
Le gros à gagner sur gint serait d'éviter le world-switch (mais ce n'est pas possible parce que le DMA est utilisé) et d'éviter la surcouche de Casio sur Fugue, et ça, c'est possible parce que je peux trouver les primitives Fugue "pure" sans trop de problèmes. À tester donc !
Outre Bfile/Fugue, le facteur limitant étant de dumper les fragments de données, mais Fugue (ou Casio je ne sais pas encore) utilise le DMA pour la lecture donc je ne pense pas qu'on puisse gagner grand-chose. Par contre, je pense qu'il y a un moyen de lire en fond les données tout en traitant / affichant les images a l'écran, ça serait assez rapide je pense.
Un avantage de lire directement en ROM si c'est possible c'est qu'on évite de copier les fragments en RAM avec BFile_Read() ou son équivalent Fugue, on peut direct les lire en ROM.
Pour les fonctions Fugue c'est pas des syscalls right? Les adresses brutes ça ne marchera pas très bien sur plusieurs OS. Si la structure est stable sur les versions qu'on a à disposition je serais plus partant pour utiliser ça, mais après bien sûr c'est si on peut le documenter.
Un avantage de lire directement en ROM si c'est possible c'est qu'on évite de copier les fragments en RAM avec BFile_Read() ou son équivalent Fugue, on peut direct les lire en ROM.
Je pense avoir suffisamment d'information sur l'architecture du FS pour m'aventurer sur la documentation des données utilisé par Fugue pour gérer la lecture de donnée. En théorie on pourrait être autonome sur la primitive de lecture seulement, mais ça pourrait avoir énormément d'avantage avec Gint.
Pour les fonctions Fugue c'est pas des syscalls right? Les adresses brutes ça ne marchera pas très bien sur plusieurs OS.
Oui les addresses seront hardcodé, mais je suis curieux de voir les perf' sans Bfile. Et ça serait sympas de voir si on peut trouver un moyen de détecter les primitives de Fugue (en théorie oui, reste à voir si on peut trouver un moyen fiable).
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
