[Bêta] PythonExtra.
Posté le 29/10/2022 09:49
PythonExtra est un add-in Python alternatif pour (à ce stade) Graph 35+E II, Prizm et Graph 90+E. L'objectif est de fournir plus de fonctionnalités : modules standard,
getkey(), fonctions de dessin plus performantes, etc.
Version Bêta 0.4 (Changelog)
Graph 35+E II / 
Prizm / 
Graph 90+E / 
Math+ / 
ClassPad : PythonExtra-pe-0.4.0-beta.zip
Aperçu de PythonExtra sur Graph 90+E. (Cliquez pour agrandir)
Description sommaire des fonctionnalités :
- Compile pour Graph 90+E (fx-CG 10/20/50) et Graph 35+E II (fx-9860G III)
- Peu de RAM sur Graph 35+E II (c'est difficile d'en trouver sur ce modèle)
- Un shell pas trop mal (saisie rapide, scrolling) avec de bonnes performances
- Plein de modules standard
- array, builtins, cmath, collections, io, math, random, struct, sys, time
- Le module spécifique CASIO : casioplot (fidèle à part sur les polices)
- Un nouveau module gint avec les fonctionnalités avancées de gint :
- Pour l'instant, une bonne partie de <gint/display.h> et <gint/keyboard.h>
- Donc getkey() (attente de touche) ainsi que keydown() (test instantané) !
- Et des fonctions de dessin rapides comme dline() ou drect()
Le plan actuel :
- Être sensiblement compatible avec l'appli Python officielle.
- Pousser les fonctionnalités ajoutées pour vraiment relever le niveau de Python !
- Si du temps de développement se débloque : support autres Graph mono (pas de promesses).
Updates et screenshots à venir. Je n'ai pas l'intention d'implémenter un million de fonctionnalités, juste ce qu'il faut pour s'assurer que ça ne finisse pas mal documenté et non maintenu comme CasioPython.
Dépôt Git :
https://gitea.planet-casio.com/Lephenixnoir/PythonExtra
PythonExtra est notamment possible grâce à l'aide précieuse de
Mb88.
Comparaison directe
Dans l'exemple ci-dessous (
réalisé par Mb88), un Flappy Bird déjà bien optimisé (dessin partiel etc, à gauche) est accéléré un bon gros coup en utilisant PythonExtra et le module
gint pour le dessin (à droite).
Contexte historique
Aux
journées APMEP 2022, redgl0w racontait comment le port MicroPython pour Numworks n'était finalement pas super difficile. Moi je parlais de comment un port maison résoudrait le problème de
getkey(), et Critor m'a convaincu d'essayer sur-le-champ.
En fin de compte, j'ai clôné MicroPython Dimanche à midi et à 1 heure du matin j'avais un port fonctionnel avec
getkey() sur ma Graph 90+E (que j'ai d'ailleurs montré à CASIO Lundi, pour la démo). Comme quoi, des fois ça marche tout seul !
(Enfin, le début marche tout seul. Faire une bonne UI et gérer tous les détails ensuite c'est une autre paire de manches !)
Fichier joint
Citer : Posté le 05/05/2025 15:20 | #
Ce code:
from utime import *
from urandom import *
def carre(x,y,c,k=3):
drect(x,y,x+c,y+c,k)
dgray(DGRAY_ON)
dupdate() # j'ai rajouté cette ligne !! (swap avec ligne suivante)
dclear(C_WHITE)
for i in range(16):
carre(randint(10,120),randint(10,50),randint(5,20),randint(0,3))
dupdate()
sleep_ms(200)
dgray(DGRAY_OFF)
getkey()
donne le même problème que le code initial de Ptitjoz...
Mystère et boule de gomme ...
Citer : Posté le 05/05/2025 15:29 | #
Je sais pas s'il y a beaucoup de façons d'interpréter « au début du programme avant tout le reste ».
(Edit: J'avais oublié que l'import du module gint passe en mode graphique aussi, donc clairement c'est pas ça.)
Sinon, ce que je vois c'est que les bandes sont blanches puis noires ce qui correspond à une valeur en mémoire de 0x55555555. Autrement dit, les VRAM du moteur de gris ne sont très probablement pas initialisées. Or, dclear() devrait les mettre à zéro. Donc faut chercher ce qui se peut se passer de travers du côté de dclear(), qui a probablement été vider la VRAM mono. (Le moteur de gris a 4 VRAM et l'une d'entre elles est la VRAM mono, mais elle ne contribue qu'à un frame sur deux).
Citer : Posté le 05/05/2025 15:36 | #
Je sais pas s'il y a beaucoup de façons d'interpréter « au début du programme avant tout le reste ».
La question, mal formulée certes
Sinon, ce que je vois c'est que les bandes sont blanches puis noires ce qui correspond à une valeur en mémoire de 0x55555555. Autrement dit, les VRAM du moteur de gris ne sont très probablement pas initialisées. Or, dclear() devrait les mettre à zéro. Donc faut chercher ce qui se peut se passer de travers du côté de dclear(), qui a probablement été vider la VRAM mono. (Le moteur de gris a 4 VRAM et l'une d'entre elles est la VRAM mono, mais elle ne contribue qu'à un frame sur deux).
J'essaierai d'y jeter un œil ce soir quand j'aurai mon PC perso sous la main. Parès faut voir si ça vient de PythonExtra ou de gint, je testerai le même programme en C pour voir si on a le même artéfact.
Citer : Posté le 05/05/2025 20:55 | #
ah ça n'a pas l'air facile de trouver la cause. Courage à vous car je ne peux pas vous aider (sauf à faire des tests). Merci en tous cas de prendre en charge ce bug