[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 07/01/2024 20:05 | #
Tiens Ptitjoz tu tombes bien.
Tu pourrais nous donner plus d'info sur le bug du ralentissement dont tu parles ici Ralentissement PythonExtra dans Emulateur car je n'arrive pas à reproduire.
Idéalement, essaye avec la dernière version de PythonExtra car il y a eu pas mal de modifs, ainsi que de gint justement sur la gestion du clavier.
Si tu as encore le bug, alors STP précise nous : le script qui plante (idéalement envoie nous le fichier .py), la version de l'émulateur et un max d'infos pour comprendre le bug.
Merci beaucoup.
Citer : Posté le 07/01/2024 21:53 | #
Tiens Ptitjoz tu tombes bien.
Tu pourrais nous donner plus d'info sur le bug du ralentissement dont tu parles ici Ralentissement PythonExtra dans Emulateur car je n'arrive pas à reproduire.
Idéalement, essaye avec la dernière version de PythonExtra car il y a eu pas mal de modifs, ainsi que de gint justement sur la gestion du clavier.
Si tu as encore le bug, alors STP précise nous : le script qui plante (idéalement envoie nous le fichier .py), la version de l'émulateur et un max d'infos pour comprendre le bug.
Merci beaucoup.
Bon, j'ai un peu cherché avec la dernière version de PE de ce jour
Premièrement, c'est un émulateur qui tourne avec Linux et wine... qui de plus sur un vieux portable, je pensais que ça venait de là.
Mais apparemment non, je crois que ça vient d'autre chose.
mon script est de mes premiers essais de faire un pong
donc j'avais codé la raquette droite avec keydown(KEY_UP) et keydown(KEY_DOWN)
et la raquette gauche avec keydown(KEY_0) et keydown(KEY_1)
et sur l'émulateur les touches du pavé numérique ne sont pas celles reconnues par PythonExtra (micropython) ! et même font ralentir et bloquent le jeu...
si je remplace KEY_0 par KEY_F2 et KEY_1 par KEY_F1 le souci disparait car les touches fonctions sont bien reconnues
si tu veux plus d'info n'hésite pas
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 13:06 | #
Enfin une mis a jour !
Citer : Posté le 08/01/2024 16:51 | #
Je confirme déjà que ça marche en l'état avec la bonne convention d'appel
On peut penser à
En gros si fill est à True, on garde la couleur de border pour remplir le cercle ou l'ellipse.
Si on veut avoir le bord d'une autre couleur, on retrace par dessus avec la couleur voulue dans border et le fill=False.
Si ni border ni fill ne sont remplis, on fait juste le contour de ellipse en C_BLACK qui est la couleur par défaut, mais au moins on a un tracé.
Qu'en penses tu ?
Edit: j'ai reformaté car c'était illisible mon précédent message
Voilà ce que j'obtiens en voulant faire plusieurs cercles pour faire une couronne (on dirait plutôt un vinyle
ça vous semble correspondre à vos attentes ?
C_Border=C_BLACK
C_Fill=True
dclear(C_WHITE)
for r in range(10,32):
dcircle(64,32,r,C_Fill,C_Border)
dupdate()
getkey()
Il y aurait la possibilité de faire des arcs de cercle par exemple pour faire une boite aux coins arrondis
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 17:56 | #
C'est pas le résultat auquel tu t'attends pour la simple et bonne raison qu'on a fait marche arrière sur l'API.
En fait il faut faire
dcircle(x, y, r, ColorBorder, ColorFill)
Pour les arcs, pour le moment on peut pas, mais je compte implémenter quelques autres primitives dont les arcs feront partie.
Pour info tu peux faire un truc du genre en attendant :
def darc( x, y, r, startangle, endangle, color):
for a in range( startangle, endangle ):
dpixel( (int(x+r*cos(a*3.1415927/180)), int(y+r*sin((a*3.1415927/180)), color )
Par exemple pour reprendre ton exemple, darc( 10, 10, 5, 90, 180, C_BLACK ).
Citer : Posté le 08/01/2024 17:58 | #
def darc( x, y, r, startangle, endangle, color):
for a in range( startangle, endangle ):
dpixel( (int(x+r*cos(a*3.1415927/180)), int(y+r*sin((a*3.1415927/180)), color )
Eh bien, il y a des maths ici...
Citer : Posté le 08/01/2024 18:04 | #
D'ailleurs je corrige les parenthèses car c'était pas ça du tout
def darc( x, y, r, startangle, endangle, color):
for a in range( startangle, endangle ):
dpixel( int(x+r*cos(a*3.1415927/180)), int(y+r*sin(a*3.1415927/180)), color )
Par exemple pour reprendre ton exemple, darc( 10, 10, 5, 90, 180, C_BLACK ).
Citer : Posté le 08/01/2024 18:05 | #
Eh bien, il y a des maths ici...
Programmer sans faire de maths, c'est en général assez compliqué
Citer : Posté le 08/01/2024 18:06 | #
d'accord merci pour tes remarques, conseils, implications
oui en trigo ce n'est pas très difficile à faire mais ce n'est pas terrible pour les perfomances
C'est documenté où toutes ces nouvelles fonctions ? (je n'ai rien trouvé sur gint) (mais je ne sais pas trop chercher)
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 18:09 | #
https://gitea.planet-casio.com/Lephenixnoir/gint/src/branch/dev/include/gint/display.h#L219-L245
C'est la branche dev de gint, c'est pas encore passé en production.
Citer : Posté le 08/01/2024 18:10 | #
J'en conviens faudra qu'on documente en // car là c'est un peu à l'arrache
Citer : Posté le 08/01/2024 18:10 | #
ah c'est pour ça que je ne trouvais rien ! merci !
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 18:11 | #
Eh oui, vous avez la primauté absolu. Servi tout chaud
Citer : Posté le 08/01/2024 18:16 | #
dcircle(64,32,r,C_Fill,C_Border)
C'est pas le résultat auquel tu t'attends pour la simple et bonne raison qu'on a fait marche arrière sur l'API.
En fait il faut faire
dcircle(x, y, r, ColorBorder, ColorFill)
.
dans la doc que tu me donnes c'est noté
donc je ne comprends plus trop ...
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 18:18 | #
La doc est OK, c'est juste que je suis vieux et je gatouille, j'ai en effet inversé fillcolor et border color
Citer : Posté le 08/01/2024 19:49 | #
Voilà ce que j'obtiens en voulant faire plusieurs cercles pour faire une couronne (on dirait plutôt un vinyle
Ha ! Ha ! Appelez-moi le prophète parce que ça je l'avais prédit. Déjà en 2019 je mentionnais que y'avait un peu trop d'options graphiques pour que ce soit facile à gérer dans gint. Le fait qu'il faille utiliser un algo différent pour les cercles fins et les cercles concentriques a toujours été un doute pour moi.
Donc oui c'est le résultat attendu, si tu veux utiliser l'algo d'Andres tu peux toujours le coder en Python (lent) ou chercher des APIs de dessin plus subtiles. Peut-être des trucs comme LVGL que circuit10 a porté l'autre jour. Si tu n'as pas besoin de préserver ce qui est dessiné au centre tu peux aussi dessiner un cercle plein noir et un plein blanc dedans.
Même catégorie je dirais, pour l'instant non. Si on veut faire du vrai rendu graphique, je ne suis pas opposé à chercher des solutions et/ou à coder plein de fonctions à la main, mais je veux un cahier des charges, on ne peut pas bien le faire à l'improviste en ajoutant des fonctions au fur et à mesure.
Citer : Posté le 08/01/2024 20:53 | #
Bonsoir Lephe .
Rassure-toi, on ne veut pas te surcharger de travail et te demander tout et n'importe quoi au fur et à mesure de nos besoins. Personnellement, c'est plutôt par curiosité que je pose quelquefois des questions. Désolé.
Personnellement je tenais à te remercier pour ce magnifique outil que tu as mis à la disposition de tous, les heures de codage, de debuguage et j'espère que tu en seras récompensé.
Bien à toi.
https://joz.alwaysdata.net/info/
Citer : Posté le 08/01/2024 20:56 | #
Oups, désolé si j'ai été un peu rude, c'était pas le but. Tu fais bien de demander, il ne faut surtout pas hésiter. Comme ça rentre dans un territoire de trucs pas du tout évident je me méfie du temps que ça risque de prendre.
Citer : Posté le 15/01/2024 10:02 | #
Bonjour
cherchant à créer un moyen de mesurer le temps, j'ai un peu regardé le module utime et fais des tests
avec ce script sous PE 2024-01-07 sur machine physique Casio Graph 35+ EII
print (ticks_cpu())
En l'exécutant plusieurs fois, la machine plante.
https://joz.alwaysdata.net/info/
Citer : Posté le 15/01/2024 10:43 | #
Ok, merci Ptitjoz, il faut qu'on teste et qu'on tracke le bug pour voir sur quoi quelle fonction pointe le PC.
On te demandera peut être des infos complémentaires.
Si je comprends bien, tu observes le bug en lançant plusieurs fois d'affilé ton petit programme qui affiche les ticks_cpu(). C'est bien cela ? Au bout d'un moment tu observes le crash en question.
Citer : Posté le 15/01/2024 10:52 | #
Alors j'ai fait un petit test rapide sur fxCG50 pour laquelle je ne vois pas apparaître le bug malgré beaucoup (mais alors beaucoup) de lancements du script.
Ma procédure de test est la suivante : script dans aaa.py
print (ticks_cpu())
J'ai lancé au moins 50 fois sans voir le crash.
Je testerai cet après-midi sur G35+EII qui dispose de nettement moins de RAM (je l'ai pas sous la main là tout de suite), peut être un pb de ce côté là. Si la procédure de test est pas la même que toi, hésite pas à explicité comment tu arrives au plantage.