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 On Saturday, November 21, 2015 at 12:33:35 PM UTC+9, Leif Theden wrote: > > 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. > > On Friday, November 20, 2015 at 1:36:27 AM UTC-6, Benjamin Moran wrote: >> >> 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 >> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
