Should pyglet's sprite class have an AABB attribute?

[Benjamin Moran]

Hi guys,

I was wondering if there was any interest in adding an AABB (axis aligned bounding box) attribute to the sprite class. It's just a couple lines of code, and it would make doing simple collision checks easier for new users. A simple property like this would suffice:

@property
def aabb(self):
    return (self._x, self._y,
            self._x + (self._texture.width * self._scale),
            self._y + (self._texture.height * self._scale))

It would be pretty easy to check if two sprites are overlapping. Here is a simple function that returns True/False (a few more calculations would tell you exact details of the overlap):

def is_overlapping(first_aabb, second_aabb):
    aleft, atop, aright, abottom = first_aabb
    bleft, btop, bright, bbottom = second_aabb
    # An overlap has occured if ALL of these are True, otherwise return False:
    return bleft < aright and bright > aleft and btop < abottom and bbottom > atop

Would something like this be considered out of scope for inclusion?  Just looking for feedback. It's easy enough to do this manually, or subclass Sprite, but I'm thinking it would be nice for new users. I see a lot of new Pygame users taking advantage of the colliderect and other built in functions that are build on top of the SDL Rect classes. Maybe it would make pyglet easier for those types of users. Maybe even include a few simple collision checks as part of the Sprite class itself would be usuful. For example :

>>> player.is_overlapping(enemy)
True
>>>player.get_overlap(enemy)
(0, 0, 2, 5)

-Ben

[Leif Theden]

I understand why some people would like this, but pyglet supports rotated sprites and I feel like AABB would be too limited. It would also open endless requests for collisions with rotated sprites, fast detection, etc. If pyglet were to include a collision detection system for sprites, it should be full featured and probably written as a compiled extension module, since the pure Python nature of pyglet would be super slow.

My suggestion would be to integrate pymunk support, or to develop a guide to using it. It's quite nice and works with pyglet just fine. Just my opinion.

[Jason Spashett]

On Friday, 20 November 2015 15:28:29 UTC, Leif Theden wrote:

I understand why some people would like this, but pyglet supports rotated sprites and I feel like AABB would be too limited. It would also open endless requests for collisions with rotated sprites, fast detection, etc.  If pyglet were to include a collision detection system for sprites, it should be full featured and probably written as a compiled extension module, since the pure Python nature of pyglet would be super slow.

My suggestion would be to integrate pymunk support, or to develop a guide to using it.  It's quite nice and works with pyglet just fine.  Just my opinion.

That's a fair point. On the other hand all the other "frameworks" have something for this. Phaser, pygame etc.It might work well for many, but not all. It is nice to get something going, even if later, it requires something like pymonk.

[Leif Theden]

Pyglet, doesn't have the same goals as specialized game libraries/frameworks like pygame or phaser.  Its been a 'multimedia library', generic enough to make games or visual demos.  Personally, I think pyglet does what it does well and shouldn't try to be a games library.  Too much bias towards games might merit a library built on pyglet (like cocos), or optional extension packages.

--
You received this message because you are subscribed to a topic in the Google Groups "pyglet-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pyglet-users/Ybr1zk6j358/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pyglet-users...@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at http://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

[Jason Spashett]

Yes, I see. I hope to use it for a touch screen application on a terminal. This is perhaps why I want to use pyglet instead of something else.

[Leif Theden]

Ben, what about an AABB class?  Pyglet devs could use them with sprites if they wanted, or GUI folks could use it for testing mouse clicks and what not.

[Benjamin Moran]

Just to clarify where I'm coming from, I wasn't thinking of integrating any sort of full blown physics engine like Pymunk (which I've used, and it's pretty nice). I was thinking these attributes would be useful to have for both games and any other applications that need to check sprite intersections (such as a point_in_rectangle function for mouse clicks).

It just dawned on me that an AABB/etc @property wouldn't even require any calculations, since the vertex_list already contains all the relevent points - you just simply return them. This is also the case for scaled and rotated sprites, but of course they are no longer "Axis Aligned" at that point.

I don't think a fullblown class would be necessary as there wouldn't be any state required, but perhaps a simple module that contains some common algorithms. Idealy, the user wouldn't have to know the math behind it, but could do some simple checks without having to understand vertex lists. If they are kept to a simple True/False return value, these calculations are very lightweight math. Such as:  aabb_overlap, point_on_line, point_in_rect, etc.

-Ben