German documentation

[ullmer]

@Mambouna -- last year, I was inspired to see lordmauve/pgzero#335 , which you titled "Docs: German translation." Did you or others by chance make headway toward that? Any thoughts whether those may be in the near or further future of pgturbo? Warmly appreciated!

[Mambouna]

Hi @ullmer, I didn't actually start work on that since @lordmauve said he'd probably just use AI to translate the docs to different languages. Since starting to work on Pygame Turbo, it has been on my todo list but I haven't gotten around to it. One big reason for that is that I am currently working on redoing the entire documentation to be more approachable for beginners.

Considering Pygame Zero and Pygame Turbo are meant for novice users, the current docs are quite difficult to navigate and cluttered. So my current plan was to restructure the documentation first and once that's done to start the work of slowly translating everything.

As such, it is not in the near future but very likely in the medium term future. If you were able and willing to help, I'd appreciate that and could let you know once the docs rework is done.

[ullmer]

Big thanks for this kind response, @Mambouna !

I personally find the example code more of a limitation than the documentation. If you or others had interest in collaborating with a few "simpler" (and perhaps iteratively more complex and express) while still highly evocative examples, I'd be delighted to do so. This could even narrowly or deeply engage the German ends, as well. My code tends to heavily engage the text facilities, and I'd be thrilled to have this be deeply multilingual, beginning with German and English. Even after a quarter-century of effort, my own German is relatively grammar-free; but 2/3 of our household is either German-first or fully bilingual (I haven't yet assessed whether our two guinea pigs are fully trilingual, or if they are more toward 2.5 languages :-), so -- I consider myself highly motivated.

[Mambouna]

I'd love help with good example games, yes!

My current thought process for how to do that would be to have one very basic but functional game as a basis. Simple mechanics but everything important is there, so actors, scheduling with clock, player input, maybe storage and some manipulation of game state. This central example would teach the basic features needed for most games. Then on top of that I was thinking of creating other examples that each introduce an advanced feature into this basic game and explore that in detail.

I'd love to see what kind of language-involved games you do, so I'd happily integrate examples that you make.

[ullmer]

Thanks much, @Mambouna! I thought I understood that you are also involved in education. I'm afraid that my inclinations toward application domains might be less "classical-game," but -- if I were to push further with (e.g.) interactive, animated visuals (and tangibles :-) engaging https://en.wikipedia.org/wiki/World_Heritage_Site , https://en.wikipedia.org/wiki/List_of_national_parks_of_the_United_States , https://en.wikipedia.org/wiki/Sustainable_Development_Goals , https://de.wikipedia.org/wiki/Pr%C3%A4ambel_zur_Charta_der_Vereinten_Nationen -- might any of those, or anything ~proximal, be more likely to appeal to your students? The first two of the above might be more image/photo-dominated; the latter two, more (multilingual) textually-oriented. (I've already implemented a good bit of the US National Parks in Pygame Zero, and some of the UN SDG.). No pressures of course; just interested to lean into examples at aspirationally Venn-intersective spaces...

I've noticed updates relating to sprites (which could intersect with my combinations of Pygame Turbo with ModernGL -- have you separated those in some cases from Actors? Any more specific GPU-engagement thus far?

Warmly appreciated!

[Mambouna]

Hi again, same reason as the other issue as to why I left you hanging, sorry about that.

I'll likely resume the effort to redo the documentation in the coming weeks.

I'm happy to include / link to any examples you've made. When I described what I was thinking about I was just talking about how to introduce learners to the package in a structured walkthrough.

About sprites: So far sprite and image are interchangeable terms in the codebase. Animation frames in the animations resource folder are made up of images that can have the same formats and limitations as static images in the images folder. The term "spritesheet" is simply such a standard for having multiple frames of an animation stored in a single image file that I've used it here as well.

To my knowledge, there are no GPU driven parts of the codebase. Any utilization of the GPU would be performed by the underlying pygame-ce dependency, not pgturbo itself.

[ullmer]

@Mambouna -- thanks much for this! If you indeed develop the German documentation further, I'd absolutely welcome a tag here or elsewhere, so that I can more swiftly explicitly link to this.

"To my knowledge, there are no GPU driven parts of the codebase. Any utilization of the GPU would be performed by the underlying pygame-ce dependency, not pgturbo itself." -- out of curiousity, do you regard this as more pragmatically or philosophically driven? If "pragmatically," how would you feel about optional mechanisms to better exploit caching of textures on the GPU side? I've been alternating between moderngl and pgturbo code for some of my mixed 2D and 3D work, and texture-caching particularly on small devices (e.g., Raspberry Pi and perhaps even pocketbeagle2, which has a GPU but no direct HDMI-out) is a principle point of interest there.

Warmly appreciated!

[ullmer]

@Mambouna -- also, if you or others had interest in collaborating on a youth-code-accessible game centering on Europe, Germany, and/or Berlin, I'd be delighted to contribute. (I spent my postdoc in Berlin, and still have family there.)

[Mambouna]

To me, the omission of GPU specific code is purely pragmatic. I am not a professional developer myself and the language I am most familiar with is Python. As such, it was approachable for me to start working of the pgzero and now pgturbo codebase, but I know little about the low level functioning of the GPU and have no experience working with lower level frameworks for GPU utilization.

Since pgturbo so far was also intended for use with education, GPU support wasn't really something I thought was "necessary", but it would of course be nice to have. The only worry I'd have about that would be possible complications of the codebase with support for different platforms and / or hardware. If GPU support would suddenly mean this hardware can use pgturbo but that other frequently used hardware can't, then I'd probably be against inclusion. If that was not the case, I would be happy to include it, but could likely not maintain that code effectively myself.

[ullmer]

@Mambouna -- thanks much! Just to confirm -- my impression is that you have neither intentionally added nor removed prior pgzero GPU engagements (if any, potentially largely implicit through pygame). Is that correct? And, I fully align with what you've described.

[Mambouna]

Yes, that is correct.