pyglet suitable Polygon subclass

[hsharrison]

I'm working on a Polygon subclass for use with pyglet, which adds the following:

• A color attribute
• A property giving the appropriate inputs to pyglet's OpenGL drawing functions, describing vector lists
• Rudimentary physics, in the form of velocity attributes and an update method. Potentially also momentum and/or acceleration.

Is this something people would be interested in or should I leave it as part of my own personal project?

If people are interested, where's the best place for it? A submodule perhaps? Wouldn't want to add the pyglet dependency to existing modules.

[sseemayer]

I think more convenient access for the different frameworks would be a great addition. I've always wanted to add support for Pygame, Pyglet and Box2D so this would be a great start.

I don't see the benefit of a Polygon subclass, though, since it forces people to use the functionality in a certain way: Some people might want to draw solid polygons, others might want to give them a texture, shaders, etc. Some people will want to use the basic physics you provide while others want to roll their own or use another library. With a subclass, users have to choose whether they want to use all the functionality (use the subclass) or none (use the baseclass). There might also be preexisting logic and accompanying class hierarchy for how a scene's updating and rendering is handled, making it impossible to inherit even from the base Py2D classes.

I would propose a more composition-based approach: simply have a module that defines a function to convert polygons into Pyglet data items, a module with a function to convert polygons to e.g. Box2D physics objects, and so on. That way, users can have their own class definitions and just pull in the functionality they want.

Regarding the placement, a submodule sounds good to me. AFAIK, As long as the code is not imported, it won't try to import pyglet.

[LBdN]

an adapters submobule gets my vote too.

On Wed, Nov 20, 2013 at 12:47 PM, Stefan Seemayer [email protected]:

I think more convenient access for the different frameworks would be a great addition. I've always wanted to add support for Pygame, Pyglet and Box2D so this would be a great start.

I don't see the benefit of a Polygon subclass, though, since it forces people to use the functionality in a certain way: Some people might want to draw solid polygons, others might want to give them a texture, shaders, etc. Some people will want to use the basic physics you provide while others want to roll their own or use another library. With a subclass, users have to choose whether they want to use all the functionality (use the subclass) or none (use the baseclass). There might also be preexisting logic and accompanying class hierarchy for how a scene's updating and rendering is handled, making it impossible to inherit even from the base Py2D classes.

I would propose a more composition-based approach: simply have a module that defines a function to convert polygons into Pyglet data items, a module with a function to convert polygons to e.g. Box2D physics objects, and so on. That way, users can have their own class definitions and just pull in the functionality they want.

Regarding the placement, a submodule sounds good to me. AFAIK, As long as the code is not imported, it won't try to import pyglet.

— Reply to this email directly or view it on GitHubhttps://github.com/sseemayer/Py2D/issues/5#issuecomment-28883367 .

Cordialement, Lionel Barret,

LBdN Consulting

http://www.lbdn-consulting.com

LinkedIn Profile : http://www.linkedin.com/in/lionelbarretdenazaris

Viadeo : http://fr.viadeo.com/fr/profile/lionel.barretdenazaris

Membre de l'Arsenal Numérique http://arsenal-numerique.org/

[hsharrison]

I didn't know about Box2D... looks interesting. I have to reconsider whether I even need what I propose here...

In any case, the adapter approach is sensible - glad I asked. If I don't end up just using Box2D for everything I'll develop it in my branch and let you know here when it's coming together.