On Fri, Jun 1, 2012 at 5:54 PM, Keith Nemitz <muse...@yahoo.com> wrote:
> > --- On *Fri, 6/1/12, Nicholas Seward <nicholas.sew...@gmail.com>* wrote: > > > From: Nicholas Seward <nicholas.sew...@gmail.com> > Subject: Re: [pygame] Improved Sprites System - Call for Suggestions > To: pygame-users@seul.org > Date: Friday, June 1, 2012, 7:50 AM > > > 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<http://mc/compose?to=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 <http://mc/compose?to=sa...@maoz.info> // +1 (347) > 556.5044 // +972 (52) 834-3339 > http://sagie.maoz.info/ http://n0nick.net/ > > /* simba says roar! */ > > > > this could go under the vis/invis or blending. Would love to have pixel and sprite transparency. Would require OpenGL, I suppose. PyGame handles per-sprite and per-pixel transparency with sprites just fine already.
