I like all of these ideas. Polygonal collisions would be very useful. (A naive O(n^2) but effective/readable/maintainable approach would be to see if any edges intersect between their vertices after you get a positive rect collision.)
An efficient spatial data structure for rendering and collision detection would really put pygame over the top. Imagine: you could prototype a scale-able CAD program in a day. If you could have a million off screen sprites without a performance dip that would be amazing. A million updates would still cause a lag but if you could turn off updates for off screen sprites except where flagged then you would have a scale-able platform. This would be one of the hardest thing on your list and most people won't ever know it is there. There is a special place in pygame heaven for the person that makes this happen. The most useful thing on your list has got to be adding visual attributes. I personally thought this was a weak area and have extended the Sprite class to hold a reference image and let me scale, rotate, and remask with ease. I only use the vanilla version when I am teaching students. Good Luck, Nicholas Seward On Fri, Jun 1, 2012 at 8:29 AM, Sagie Maoz <sa...@maoz.info> wrote: > Hi guys, > > As part of my GSoC project [1], I've been researching Pygame's sprite.py > and equivalents in other libraries, figuring out a list of features I will > focus on in my project. > > I wanted to get your thoughts and feedback on these items; which of these > do you think are necessary, and which more necessary than the others? Do > you think implementing any of these would be too difficult for a first-time > contributor (me)? Do you have any other ideas? > > Suggested improvements for sprite.py: > 1. Easier positioning methods: Using tuples or arrays, instead of just > Rects. > 2. Setting a sprite's anchor points for handling in movement, animation, > collision etc. > 3. Aggregated sprite class (basically, a sprites group which implements > the sprite interface). > 4. Automated dirty rendering (existing feature in Spyral [2]). > 5. New visual attributes for sprites: > - Rotation angle > - Scale > - Crop rectangle > - Visible/hidden > - Collision parameters (smaller hitbox, etc.) > 6. Alternative forms of collision detecting (not limited to circles and > rectangles). > Possibly using algorithms such as quadtrees and spatial hashing. > 7. Improved layering system. > 8. Respecting blendmode flags are handled in all types of sprites. > 9. Animated sprites: > - Setting a group of images to cycle through in a time interval. > - Animating visual attributes, a-la Kivy [3] or CSS transitions [4]. > 10. Events dispatching from groups to sprites. > > This list was comprised after consulting with mentor Robert Deaton > (masquerade) and fellow contributors on the IRC channel. > It's obviously not a final list of the work I'm planning, but more of a > list of things to research before I get to coding. > > I would love to hear your feedback on these. > > Thanks, > > [1] Pygame SoC application: Improved Sprite and Scene system > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/n0nick/28002 > [2] Spyral http://www.eecis.udel.edu/~rdeaton/spyral/ > [3] Animation in Kivy http://kivy.org/docs/api-kivy.animation.html > [4] CSS Transitions https://developer.mozilla.org/en/CSS/CSS_transitions > > -- > Your friend in time, > Sagie Maoz > sa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339 > http://sagie.maoz.info/ http://n0nick.net/ > > /* simba says roar! */ > >
