You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue №3444 opened by novialriptide at 2022-09-11 17:57:03
Similar to pygame.Rect, it will support collisions, pygame.draw, etc.
@itzpr3d4t0r, @Emc2356, and I have been working on this very project on a different repository under my profile and development is going pretty smoothly so far, but the main problem here is public opinion.
Do we really need this? This is not an SDL wrap implementation like pygame.Rect. Another thing is that @Starbuck5 hopes that this would be under pygame.geometry instead of pygame.circle.Circle, pygame.polygon.Polygon, etc, which I don't mind, but we also need more opinions on that.
This has been previously discussed in # 3336. Should this be closed as a duplicate?
I don't think so, as the former is just a single comment of yours about an idea and the project has evolved significantly since then. Because of this i think we need a separate space to discuss stuff and keep things more organised. I propose you close # 3336 instead as we won't have separate collision algorithms but rather will be object member methods.
The design for its API will be very similar to the existing pygame.Rect, except each object will contain its own special attributes such as is_parallel() for Line, circumference for Circle, points for Polygon, and most importantly: collideswith() implemented in every object.
I can't represent the entire community, but so far we've gotten support within the pygame community Discord server, but that's pretty much it. I can offer to create a Reddit post in r/pygame as well to further our reach.
None at the moment.
As mentioned before, @itzpr3d4t0r, @Emc2356, and I have been working on a prototype for this implementation in C here. @Starbuck5 has also been at work on reviewing our PRs in the repository. It's still a work in progress though. Some other modules that support Polygons, Circles, and Lines are pymunk, pythonarcade, and there's even a tutorial on how users can implement these type of collisions themselves in a GitHub Gist here. I don't think it's a good idea for users to be relying on other libraries to create/use libraries outside of pygame for these shapes. If someone wanted to use these shapes, then they would need to learn an entirely new library, and seeing that pygame is the most popular first library, I don't think any beginner is up to that task.
This would be a very welcome addition. Adding the ability to detect collisions with polygons would allow for consistency with rects. I also really like the idea of a generic "collideswith" as a general solution to collisions. (In my current course, I teach how to do a point collision in a circle, but it would be great to have this capability built in to all shapes - including polygons.)
Issue №3444 opened by novialriptide at 2022-09-11 17:57:03
Similar to pygame.Rect, it will support collisions, pygame.draw, etc.
@itzpr3d4t0r, @Emc2356, and I have been working on this very project on a different repository under my profile and development is going pretty smoothly so far, but the main problem here is public opinion.
Do we really need this? This is not an SDL wrap implementation like pygame.Rect. Another thing is that @Starbuck5 hopes that this would be under
pygame.geometry
instead ofpygame.circle.Circle
,pygame.polygon.Polygon
, etc, which I don't mind, but we also need more opinions on that.Any support or oppositions?
Comments
# # DatDerpyDude81 commented at 2022-09-12 01:40:53
YES YES YES it will make hitboxes much easier.
# # Starbuck5 commented at 2022-09-12 06:48:26
This has been previously discussed in # 3336. Should this be closed as a duplicate?
# # itzpr3d4t0r commented at 2022-09-12 08:42:00
I don't think so, as the former is just a single comment of yours about an idea and the project has evolved significantly since then. Because of this i think we need a separate space to discuss stuff and keep things more organised. I propose you close # 3336 instead as we won't have separate collision algorithms but rather will be object member methods.
# # novialriptide commented at 2022-09-12 18:56:40
Can I have permission to link the geometry project here?
# # illume commented at 2022-09-13 12:40:50
I'd like to know:
# # novialriptide commented at 2022-09-13 13:33:22
pygame.Rect
, except each object will contain its own special attributes such asis_parallel()
forLine
,circumference
forCircle
,points
forPolygon
, and most importantly:collideswith()
implemented in every object.Polygon
s,Circle
s, andLine
s are pymunk, pythonarcade, and there's even a tutorial on how users can implement these type of collisions themselves in a GitHub Gist here. I don't think it's a good idea for users to be relying on other libraries to create/use libraries outside of pygame for these shapes. If someone wanted to use these shapes, then they would need to learn an entirely new library, and seeing that pygame is the most popular first library, I don't think any beginner is up to that task.# # IrvKalb commented at 2022-09-13 17:07:31
This would be a very welcome addition. Adding the ability to detect collisions with polygons would allow for consistency with rects. I also really like the idea of a generic "collideswith" as a general solution to collisions. (In my current course, I teach how to do a point collision in a circle, but it would be great to have this capability built in to all shapes - including polygons.)
# # clear-code-projects commented at 2022-09-14 10:20:23
I think a more generic geometry class would be really good. Hitboxes would benefit from it a lot!
# # ScriptLineStudios commented at 2022-09-15 06:02:05
I really like the sound of this! Especially polygon hitboxes would be a great feature.
The text was updated successfully, but these errors were encountered: