[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Improved Sprites System - Call for Suggestions


this could go under the vis/invis or blending. Would love to have pixel and sprite transparency. Would require OpenGL, I suppose.




--- On Fri, 6/1/12, Nicholas Seward <nicholas.seward@xxxxxxxxx> wrote:

From: Nicholas Seward <nicholas.seward@xxxxxxxxx>
Subject: Re: [pygame] Improved Sprites System - Call for Suggestions
To: pygame-users@xxxxxxxx
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 <sagie@xxxxxxxxx> 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

-- 
Your friend in time,
Sagie Maoz