That is not a good idea as only cpython 3.11 began to support emscripten, and support is dropped in 3.13 this month.
i’d say 3.12 is the wasm stable version especially when compiled with GitHub - pygame-web/python-wasm-sdk: Tooling for building CPython+support libs on WebAssembly where most cpython requirements have been pre adjusted, and some critical fixes for emsdk (reviewed but still waiting for approval or merge)
i maintain Panda3D wheels for cpython-wasm ( a bit like pyodide but posix ) through pygame-web cdn. eg https://pygame-web.github.io/showroom/pypad.html#src/test_panda3d_cube.py
3.11 ( numpy also avail )
3.12 wheel for cpython-wasm archives/repo/pkg/panda3d-1.11.0-cp312-cp312-wasm32_bi_emscripten.whl at main · pygame-web/archives · GitHub ( no numpy )
for people who don’t want to rebuild the whole stuff ( it is indeed quite complicated ) and just want test against existing code and rewrite/test shaders
You can just package your game with pygbag tool, a bit of doc here pygame-web.github.io | Run python and pygame code in your html
srgb does not work for now so don’t be surprised, the whole is still very experimental and volatile so current help is on discord ( Help channel subthread WebBuilding )
@FRPS_Archy most of your linking problems come from 32/64 bits interface mistmatch. either remove bigint support on both cpython and panda ( making it MVP wasm 1.0 compliant) or add bigint to both ( that allows to reuse most 3.11 pyodide wheels )
another way when using an mvp cpython is to normalize python modules ( .so ) with wasm-emscripten-finalize -mvp before linking or dynamic loading