Description
Issue №1498 opened by robertpfeiffer at 2019-11-11 10:49:50
Related to # 837, # 1068, # 1434, # 1357, # 1152
We should think about adding additional information to the Sprite class, so that future renderers or sprite groups could make use of that information. For regular Sprite instances, these values would simply default to the most dynamic/compatible values.
# Part I
I propose the following:
- immutable (default=False) - Can the image be modified/blitted/painted over or swapped out?
- animated (default=True) - Can the image be swapped out for another image?
- static (default=False) - Is the sprite's rect known to not move?
- depth/z-index (default = 0.0)
because they would be useful for sprite batching. Sprite/Group subclasses could implement different behaviour for static and movable sprites, or mutable and immutable.
The idea here is basically just to add information that would be useful for renderer/GL code to Sprite, without making Sprite depend on or refer to Renderer/GL modules.
# Part II
IIRC HaxeFlixel Sprites also have these by default:
- velocity
- health
- rotation
- scale
- shaders
These would be harder to support in a backward-compatible fashion, as a Sprite with these fields set to non-default values would need to be handled differently by a blit-based renderer, and rotation doesn't play nice with rects.
# PART III
This is definitely reserved for pygame 2.1, but maybe worth talking about now.
For data-oriented shenanigans, a Sprite would need to have a list of components, and component systems would have to have a list of Sprites that have these components/a list of components. That part can easily be implemented with Cython, and it would run fast. We could have a ComponentSystem class, an .addComponent(self, system) method on sprites, and a couple of standard components.
To make this system actually useful, we would need a way for users to write their own fast ECS code.
Can we expose the Component Cython to users, so they can write ComponentSystem subclasses in Cython? These could then have .update() methods written in Cython that iterate over Components of Sprites in tight inner Cython loops, without ever doing dynamic look-up of instance fields.
Alternatively, is there a way to build/distribute modules that link against pygame, and use the Cython/C api?
Related Docs: https://www.pygame.org/docs/ref/sprite.html
Comments
# # mcpalmer1980 commented at 2019-11-14 19:35:16
Backwards Compatibility
The changes you suggest in Part 2 shouldn't effect legacy code. The old code will run, but with rotation and such ignored. As I said elsewhere, this seems fine to me. It is very important that pygame2 runs old pygame code, but that doesn't mean we need to support new pygame2 features with software blitting, does it?
It's not realistic to expect a modern game framework to support systems that lack GPU rendering, and doing so will likely limit pygame2's potential.
Component System
Your component system sounds interesting but its purpose remains vague. I imagine something like a transform component that will handle acceleration, rotations deltas, etc, a viewport component that will provide a global transform for scrolling and camera rotation, and an animation component that will cycle through a list of frames.
Are these the kinds of components you're suggesting?
Should we discuss the pros/cons of implementing such a system as opposed to just adding the most common/useful features directly to the sprite or image class, such as those requested for transform_and_draw in() # 1185?
# # mcpalmer1980 commented at 2020-04-10 16:54:07
Wow, 5 months without a single reply :(
# # nthykier commented at 2020-04-26 08:40:51
I think it would make sense to work on this as a part of 2.0 rather than 2.1 (i.e. finish parts of it in 2.0 possibly leave harder/later parts to 2.1) as I can see it being a selling point for Pygame 2.
@robertpfeiffer: Do you have any patches/issues pending review for this feature that we can look at now?