Let's play: proposal to upstream picogame
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- c
- Área
- embedded-iot
Línea de trabajo
The issue proposes upstreaming the picogame C module but does not name CircuitPython files, tests, or an implementation entry point. First read the linked picogame engine overview and review the repository's process for adding C modules and board build options. The immediate outcome is a maintainer decision on scope, ROMFS and Core1 requirements, and distribution; implementation work is not yet defined.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
It's been a year since I started working on the picogame game engine https://picogame.makerclass.cz/.
In my opinion, it is ready for the next step. Over the last two months I haven't had to change anything in its core API except adding new primitives for the 3D helpers, so I consider it stable - and by now dozens of users have run it on their own boards, some have built their own games with it. I'd like to discuss integrating the C module into CircuitPython.
I also need help deciding a few details about how to finalize the engine, and what requirements would Adafruit have for it.
Two features still need a direction:
-
Core1: on SPI boards this adds about 30 % performance for pseudo-3D scenes; on the Fruit Jam without USB host it generally adds about 50–70 % for full-motion games. In reality this is primarily a benefit for 3D scenes, which picogame wasn't originally designed for. The question is whether it makes sense to keep improving this aspect.
-
ROMFS asset partition: for games with large assets, a small flash partition (e.g. 32–96 kB carved from the CIRCUITPY drive) that the engine can blit from directly - assets then cost zero RAM, which unlocks much better-looking games. It requires a partition layout change, so I'd like to hear how you'd prefer that to be handled.
I'd also like to discuss distribution. I would enable picogame on the PicoPad board I maintain (https://circuitpython.org/board/pajenicko_picopad/), and I think it makes sense enabled on other gaming boards and the Fruit Jam. It's useful on a bare Pico too, but there it probably shouldn't be on by default - for those maybe a separate build variant, similar to how the Zephyr builds, should be nice.
A few details: the whole C module costs about 37 kB of flash on a PicoPad with optimized compile flags (~6 kB of that came with 3D). The C module is fully usable on its own - see https://picogame.makerclass.cz/concepts/engine-only/ - the rest of the engine is 30+ Python libraries that would stay a normal library bundle outside the tree: they abstract the hardware (GPIO buttons, USB gamepads/keyboards and I2C pads all behave the same), audio and other conveniences, configured through settings.toml so boards and peripherals can be tuned without touching game code. The engine is covered by a desktop simulator, a browser (WASM) build and a benchmark suite, and 40+ existing games and demos serve as a regression corpus - all of which I intend to keep maintaining.
What should be the next step?
- Lenguaje dominante
- C
- Estrellas
- 4.6k
- Forks
- 1.4k
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 155
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de adafruit/circuitpython
-
board breaks api
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
adafruit/circuitpython#11099 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
storage usb zephyr
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
adafruit/circuitpython#11531 ·
Los mantenedores suelen responder en 1 día
-
Move silabs to ZephyrAbiertosilabs
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
adafruit/circuitpython#11507 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Feature/API request: portable camera capture across ESP-IDF, Zephyr, and parallel interfacesPosiblemente ocupada @tannewt la tomó hace 1 día. Abiertocircuitpython api displayio enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
adafruit/circuitpython#11505 · 5 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
adafruit/circuitpython#11472 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de adafruit/circuitpython
Issues similares
-
Warps 4 unit tests (raalloc)Abiertoenhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Policy query leaks host primary block (BSL_PrimaryBlock_deinit skipped) on two early-exit pathsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
NASA-AMMOS/BSL#355 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
arancormonk/dsd-neo#660 ·
Los mantenedores suelen responder en 1 día
-
[Bug]: remote-ls --updates reports up-to-date OCI refs because it ignores deployed Alt-idPosiblemente ocupada @Joao-kouznetz la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día