Salut, pour la Pycon DE 2022 j’avais envisagé de faire tourner Pygame directement dans les navigateurs internet ( via WebAssembly, sans installation, ni serveur web dynamique* ).
Ayant réussi à temps, j’ai ultérieurement créé un petit outil d’aide à la publication pour que tout le monde en profite ( même sans linux ni compilateur, juste python 3.8+ ):
Je suis dispo pour aider tout participant potentiel voulant release avec pygbag ( avec pyinstaller qui est souvent flag en virus, personne n’a plus trop envie de tester des .exe sur itch ).
re, juste pour signaler que les problèmes de sons ont été fixés
et que maintenant pygbag peut générer des “scripts” autonomes qui fonctionnent aussi bien sur le web que localement avec “python -x page.html” ( en remettant au goût du jour un vieux hack pour MS-DOS inclu dans CPython )
Je ne me rends pas bien compte de ce que ça représente comme travail à faire tout ça : tu adaptes la lib pour la rendre compatible avec un compilateur Python→JS ? (ou WASM ?)
Ce serait une « recette » applicable à d’autres bibliothèques graphiques par exemple (je pense notamment à pyglet) ?
alors impossible de prévoir si un module va accepter wasm sans poser de problème : il faut essayer et espérer qu’il n’y aura pas une cascade de mésaventures. C’est pour ça que je ne porte que des gros modules bien liés à cpython depuis longtemps et multiplateforme.
Ce n’est pas vers JS mais bien vers WASM qui est un cpu à part entière ( et emscripten ou wasi les OS posix qui “tournent” dessus ). C’est donc un peu comme ajouter un module sur kivy/android
Des fois un simple /opt/python-wasm-sdk/python3-wasm setup.py bdist_wheel fera l’affaire, des fois c’est une cascade d’incompatibilités avec la cross-compilation ( eg Pillow ) à cause d’un setup.py inadapté.
Donc oui la recette est applicable partout, mais déjà par exemple pyglet par défaut fait de l’OpenGL alors que le web n’autorise que GLES donc à tester …
nb: tous les imports de roues doivent être fait dans le __main__
Car les imports d’un fichier importé ne seront pas détectés : le chargeur “devine” les roues à importer par parsing du code du point d’entrée.
J’ai une question, (je ne suis pas sur de la poser au bon endroit…) .
J’ai fais un jeu dans un style “streetfighter” avec pygame. Le jeu se lance bien dans le navigateur, mais la vitesse du jeu semble limitée. Elle semble notamment décorrélée de la définition des FPS donnée dans python (qui lui marche normalement quand on le compile).
Je n’ai pas les connaissances me permettant de trouver la solution à ce problème, qui es peut être lié à la partie HTML…
En vous remerciant
Salut, pour les réponses approfondies il y a le discord de afpy avec les sections “hors sujet” ou “entraide” qui font tres bien l’affaire. Sinon coté FPS c’est simple ce n’est pas python qui décide du tout ni même pygame : c’est le fabriquant du périphérique qui fixe le nombre d’image par secondes des navigateurs ( sur PC ça devrait etre 50 ou 60 ips pour la plupart des écrans ). Et donc il faut adapter les animations en fonction du delta T qui est fixé ( il peut etre nécessaire de faire de l’interpolation linéaire mais en prenant 30 images par seconde comme base d’animation on arrive à s’en tirer assez facilement)