Google Groups

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

DR0ID Jun 4, 2012 12:47 PM
Posted in group: pygame mirror on google groups
On 03.06.2012 01:47, Christopher Night wrote:
On Sat, Jun 2, 2012 at 1:50 PM, DR0ID <> wrote:
On 02.06.2012 16:46, Christopher Night wrote:
On Fri, Jun 1, 2012 at 2:29 PM, DR0ID <> wrote:
On 01.06.2012 15:29, Sagie Maoz wrote:
2. Setting a sprite's anchor points for handling in movement, animation, collision etc.
5. New visual attributes for sprites:
   - Rotation angle
   - Scale  
2. the sprites anchor point should be just an offset, not limited to 'topleft', 'midtop', 'topright',... and the other rect attributes

I want to be able to specify "center" or "midbottom" for the sprite anchor without knowing the image's dimensions. And I want that anchor point to remain in the appropriate place even if the image is rotated, scaled, or flipped. I'm not sure that an offset would accomplish this, but if so, then that's okay.



I agree, what I suggested is that both things should be possible: a general offset and/or specifying 'center' or 'midbottom' or....

I'm not sure right now how the math to maintain the point at the appropriate place. Maybe this needs some more specification for the different transformations (rotation, flip, scale).

Well the desired behavior is pretty straightforward to me. Say I specify a sprite's anchor as "midbottom", and the sprite's image has a single orange pixel at its mid-bottom. Then if I ask to draw the sprite at (200, 100), then that orange pixel should wind up at (200, 100) no matter how the sprite is transformed (maybe one pixel off because of rounding). The math shouldn't be too hard to work out from that.


Hi once again

In the mean time, I have implemented such a system that leaves the anchor where it is, but I run into a problem: the order of applying the transformations. It's not exactly the same if you first flip and then rotate or the other way around, first rotate and then flip. To see better what I'm talking about:

What is more useful?

As for now my implementation does first rotate and then flip, because that looks like the behavior I would want if I write a platformer or similar game. I then have thought about how many cases a flip and rotation would be used on the same sprite at the same time and I think there are not that man occasions. But maybe I'm wrong.

As for scaling it does not matter when it occurs, although I use rotozoom (which has an annoying black border when rotate by a multiple of 90 degrees, which looks like the entire image is shifted by 1 or 2 pixels for whatever reason, bug! bug!, also not sure how transparency is handled by it).