[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.2
Graph 35+E II / 
Prizm / 
Graph 90+E : PythonExtra-pe-0.2.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 03/02/2024 16:27 | #
Nope. Fais voir ton code ?
Citer : Posté le 03/02/2024 16:54 | #
Voila :
b=True
print("Pressez une touche")
while b :
a=gint.getkey()
if a.key == gint.KEY_EXE :
print("La touche EXE")
if a.key == 0x92 :
print("La touche F2")
if a.key == 0x93 :
print("La touche F3")
if a.key == 0x94 :
print("La touche F4")
if a.key == 0x95 :
print("La touche F5")
if a.key == 0x96 :
print("La touche F6")
if a.key == 0x96 :
print("La touche F6")
Citer : Posté le 03/02/2024 17:01 | #
Aaah, c'est pas ta faute. Le problème est le suivant. Le nouveau texte dans la console est bien ajouté instantanément. Mais quand tu print(), PythonExtra n'affiche pas immédiatement (sinon ça serait hyper lent quand tu print beaucoup). À la place, il se note d'afficher 100 ms plus tard. Sauf que pour l'instant (et c'est là le problème) il ne fait l'affichage qu'entre deux lignes de code donc il faut attendre que le getkey() suivant soit fini avant que le texte ne se voie.
Je vais voir pour corriger ce problème. Il ne devrait rien y avoir à changer dans ton code.
Citer : Posté le 03/02/2024 17:02 | #
tu peux le réduire en ca:
b=True
print("Pressez une touche")
while b :
a=getkey().key
if a == KEY_EXE :
print("La touche EXE")
if a == KEY_F2 :
print("La touche F2")
if a == KEY_F3 :
print("La touche F3")
if a.key == KEY_F4 :
print("La touche F4")
sinon je ne vois pas le probleme
EDIT: bien joué Lephe'
Citer : Posté le 03/02/2024 18:03 | #
Juste au cas où, le flappy bird pour g90, dans le dossier exemples, il y a un petit souci avec l’affichage du score quand on perd, il ne s’affiche rien du tout
Citer : Posté le 03/02/2024 20:49 | # |
Fichier joint
@Le_masque Voici ci-joint une version de PythonExtra dans laquelle ton problème de getkey() devrait être corrigé. Peux-tu tester et me confirmer ? Tu peux aussi essayer le fichier ex_getkey.py du dossier examples qui fait quelque chose de similaire.
S'il y en a qui veulent tester les images et tout le bordel annoncé récemment sont aussi dans ce build.
Citer : Posté le 03/02/2024 20:54 | #
[..]Pour le dessin concurrent as-tu confirmé s'il y a bien un dupdate() ou équivalent entre le dernier print() et le début du dessin du frame graphique ?[..]
Apparemment , non il n'y avait pas de dupdate().
Dans mon cas, les print() étaient pour avoir des informations de debugage et je n'avais pas pensé à mettre à jour l'affichage car naïvement je pensais que ça ne s'appliquait qu'aux objets graphiques.
https://joz.alwaysdata.net/info/
Citer : Posté le 03/02/2024 20:56 | #
C'est plus ou moins le cas. Le dupdate() ici ne sert pas à mettre à jour le shell. Il sert à indiquer (implicitement) au shell que tu reprends le contrôle du dessin, ce qui évite au shell de dessiner en même temps que toi.
Citer : Posté le 04/02/2024 00:37 | #
@Lephenixnoir , j’ai teste la nouvelle version et c’est bon le problème est résolu
Juste, est ce normal qu’il n’y ait écris « 490376 » devant le curseur dans le shell ?
Citer : Posté le 04/02/2024 07:15 | #
Excellent ! Oui le 490376 c'est la quantité de mémoire qui reste dans la zone de mémoire principale. C'est juste du debug pour moi ça me sert sur 35+E II pour surveiller si la mémoire se vide
Citer : Posté le 04/02/2024 18:32 | #
Update : en voulant prendre des screenshots pour faire la doc j'ai remarqué que PythonExtra crashe au démarrage sur 35+E II quand j'active les fonctions de debug. En fait il apparaît que la consommation mémoire au démarrage (principalement durant la recherche des fichiers .py) est limite limite, si bien qu'avec les variables de debuggage en plus (... i.e. tout le driver USB !) ça passe plus.
Je m'attaque donc à une réduction de la consommation mémoire. Faut faire un truc là. J'ai plusieurs idées, je vous dirai...
Citer : Posté le 04/02/2024 19:28 | #
J'ai une question a propos de gint, a quoi sert getkey_opt?
Citer : Posté le 04/02/2024 19:32 | #
C'est une version généralisée de getkey() avec plus d'options. En gros tu peux contrôler si SHIFT/ALPHA sont autorisés, si tu as le droit de revenir au menu, modifier le rétroéclairage, ou éteindre la calto. Et tu peux aussi spécifier un délai maximal après lequel la fonction retourne si l'utilisateur ne fait rien. Je l'ajouterai à la doc bientôt...
Citer : Posté le 04/02/2024 19:34 | #
C'est une version généralisée de getkey() avec plus d'options. En gros tu peux contrôler si SHIFT/ALPHA sont autorisés, si tu as le droit de revenir au menu, modifier le rétroéclairage, ou éteindre la calto. Et tu peux aussi spécifier un délai maximal après lequel la fonction retourne si l'utilisateur ne fait rien. Je l'ajouterai à la doc bientôt...
Citer : Posté le 04/02/2024 19:35 | #
L'événement renvoyé par getkey() a des champs .shift et .alpha en plus du .key. Ces deux champs indiquent si SHIFT ou ALPHA étaient utilisés. Tu peux voir quelques détails par ici dans la doc : https://gitea.planet-casio.com/Lephenixnoir/PythonExtra/src/branch/dev/docs/sh/modgint-fr.md#%C3%A9v%C3%A9nements-clavier
Citer : Posté le 04/02/2024 23:11 | #
Je m'attaque donc à une réduction de la consommation mémoire. Faut faire un truc là. J'ai plusieurs idées, je vous dirai...
Bon du coup c'est pas mal. J'ai fait les premières choses que j'avais en tête. D'abord j'ai ajouté de quoi surveiller la consommation en mémoire quand le mode debug est activé, ce qui sort sur le log USB ce genre de lignes au démarrage :
console: _uram[used=3232 free=5644] pram0[used=2400 free=161336]
upy: _uram[used=3232 free=5644] pram0[used=2400 free=161336]
prompt: _uram[used=3372 free=5496] pram0[used=2400 free=161336]
ui: _uram[used=4296 free=4524] pram0[used=2400 free=161336]
Assez explicite je crois, y'a deux arènes, plus used est petit et plus free est grand mieux c'est.
Une bonne partie du gain mémoire a été de déplacer un tableau pré-alloué de 200 lignes vides pour le shell de la RAM principale (_uram) vers une nouvelle arène dans PRAM0 (pram0). PRAM0 est immense par comparaison avec le reste (160 kio) mais pour des raisons dans lesquelles je ne rentre pas ici on ne peut s'en servir que pour stocker des types de données explicitement prévus pour. J'ai modifié le type des lignes pour qu'il soit stockable dedans, et pouf ça fait 2400 octets virés du tas principal.
À cela je crois encore pouvoir ajouter un chouille de RAM à grapiller et diverses optimisations consistant à rendre certaines données plus compactes. Je vous dirai.
Comme c'est une side-quest de ma tentative de prendre un screenshot (qui marche maintenant), dans le but de faire de la doc, je n'ai pas encore mergé la PR de Sly avec les modules Numworks.
Citer : Posté le 05/02/2024 10:21 | #
Excellent ! Oui le 490376 c'est la quantité de mémoire qui reste dans la zone de mémoire principale. C'est juste du debug pour moi ça me sert sur 35+E II pour surveiller si la mémoire se vide
Je viens d'essayer sur l'émulateur et il n'y a pas beaucoup de mémoire, mais je ne sais pas si ça veut dire grand-chose sur l'émulateur.
Sinon, en faisant faire cohabiter sur la machine physique deux ou plusieurs versions de PythonExtra (en ayant eu soin de renommer les fichiers *.g?a) cela ne semble pas poser de problème et cela permet d'isoler le PE fonctionnel de ceux de test et de pouvoir comparer.
Le seul petit ennui, c'est la même icône, mais comme c'est par ordre d'arrivée, ce n'est pas gênant.
Bien à toi
https://joz.alwaysdata.net/info/
Citer : Posté le 05/02/2024 11:53 | #
Tu peux utiliser l'add in Icone pour changer les icônes des add-ins
Citer : Posté le 05/02/2024 14:44 | #
Je me note de regarder si je peux ajouter une option pour les builds expérimentaux qui change d'icône.
Citer : Posté le 05/02/2024 14:51 | #
Je me note de regarder si je peux ajouter une option pour les builds expérimentaux qui change d'icône.
Alright, j'ai fini de tester/valider le rendu d'images sur Graph mono. Voilà un exemple final qui démontre plusieurs images, montre qu'on a de la transparence en plus du noir et blanc, qu'on peut afficher des morceaux d'images, et enfin montre que si on crée l'image avec un bytearray on peut ensuite modifier les pixels.[..]
lien du post
j'ai importé ton script sur l'émulateur, voila ce que ça donne (la même chose évidemment).
Merci pour les exemples de code concrets que tu nous fournis,
https://joz.alwaysdata.net/info/
Citer : Posté le 07/02/2024 09:29 | #
Bug trouvé: quand j'allume PE, je vais dans un dossier et que je sélectionne mon jeu de flappy bird, tout se passe bien. Je joue un peu, et quand je clique sur QUIT dans le menu du jeu, le jeu se termine comme prévu. Quand je revient sur File en appuyant sur F1, et que je appuie sur EXIT pour quitter le dossier et aller a la racine de la calculatrice, il me met Système ERROR et je doit appuié sur EXIT et ça restart la calculatrice. Je ne sais pas si j'ai été clair, si non, dite le moi
Sinon, j'ai une question, PE est codé en C ou en C++? Car j'aimerais bien contribuer au code maintenant que je maîtrise le C a 70%. Si c'est en C++, je ne pourrai pas le faire maintenant car je suis en train de l'apprendre
Bonne journée
Tuper