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.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> 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 maozsa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339
http://sagie.maoz.info/ http://n0nick.net/
/* simba says roar! */
