Sprite "anchor" points

[David Eyk]

What are the chances of Sprite getting some new anchor points, such
that a Sprite's position can be read and set using the following
relative positions:

##### Begin python
s = pyglet.Sprite(...)
assert s.bottom == s.y
assert s.center_y = s.y + (s.height // 2)
assert s.top == s.y + s.height

assert s.left == s.x
assert s.center_x == s.x + (s.width // 2)
assert s.right == s.x + s.width

assert s.bottomleft == (s.bottom, s.left)
assert s.topleft == (s.top, s.left)
assert s.topright == (s.top, s.right)
assert s.bottomright == (s.bottom, s.right)

assert s.center == (s.center_x, s.center_y)
##### End python

This would be easily accomplished using simple properties. I'd be
happy to submit a patch, if the above API was agreeable.

An alternative approach would be to implement some sort of Rect object
(a la Pygame) and use that to ultimately determine the position of the
sprite. This might be nicely paired with the above properties
ultimately proxying the attributes on the rect, but I don't consider
it a crucial feature.

--David Eyk

[Alex Holkner]

On Fri, May 2, 2008 at 12:16 AM, David Eyk <davi...@gmail.com> wrote:
>
> What are the chances of Sprite getting some new anchor points, such
> that a Sprite's position can be read and set using the following
> relative positions:
>
> ##### Begin python
> s = pyglet.Sprite(...)
> assert s.bottom == s.y
> assert s.center_y = s.y + (s.height // 2)
> assert s.top == s.y + s.height
>
> assert s.left == s.x
> assert s.center_x == s.x + (s.width // 2)
> assert s.right == s.x + s.width
>
> assert s.bottomleft == (s.bottom, s.left)
> assert s.topleft == (s.top, s.left)
> assert s.topright == (s.top, s.right)
> assert s.bottomright == (s.bottom, s.right)
>
> assert s.center == (s.center_x, s.center_y)
> ##### End python
>
> This would be easily accomplished using simple properties. I'd be
> happy to submit a patch, if the above API was agreeable.

I'm not especially keen on it, to be honest. I know Richard likes
these properties at least, though.

Be aware that your implementation above is incorrect, it doesn't take
into account the image's anchor_x and anchor_y properties, the
sprite's scale (and how are you going to deal with the sprite's
rotation?).

Alex.

[David Eyk]

On May 1, 10:01 am, "Alex Holkner" <alex.holk...@gmail.com> wrote:
> I'm not especially keen on it, to be honest. I know Richard likes
> these properties at least, though.

It seems a nice convenience to me, and could lead to less cluttered
code, encapsulation and all that. I'm curious: what argument would
you have against it, beyond preference?

> Be aware that your implementation above is incorrect, it doesn't take
> into account the image's anchor_x and anchor_y properties, the
> sprite's scale (and how are you going to deal with the sprite's
> rotation?).

I was assuming the bottom left corner, but as I look into it a bit
further, I see your point. Are anchor_x and anchor_y recent? Or have
I just been missing them?

In my defense, I'll point out that my above code is a test case, not
an implementation. No scale or rotation are set, so the test case
*might* pass, if the anchor is set at bottom left. :) But I'll admit I
hadn't taken those into account either. :( I haven't looked into how
rotation and scaling work, so perhaps the implementation wouldn't be
as simple as I had thought.

Thanks for your response. I will take a closer look at these things
when I have a chance, if not for a patch, at least for a subclass.

--David