Just in case anyone comes across this old conversation,
I've added my Aseprite codec to the pyglet/contrib directory. I've also
included an example of how to add codecs at runtime through the
"pyglet.image.codec.add_decoders(codec_module)" mechanism. This might serve
as a good example if someone else wants to write custom image codecs in the
future.
The codec itself is complete, except for the blend modes between layers. It
supports only "normal" blending, which is all I've ever used. Other
blending modes would be trivial to add to this codec, should someone want
to use it in their game/application.
-Ben
On Saturday, February 4, 2017 at 12:21:06 PM UTC+9, Benjamin Moran wrote:
>
> It's definitely a deal breaker for me, since that's one of pyglet's strong
> points. I'll have to think about this a bit more. At the least, I'll make a
> standalone loader module that returns Animations, and drop it into the
> contrib folder.
>
>
> On Friday, February 3, 2017 at 5:00:43 AM UTC+9, Kale Kundert wrote:
>>
>> Yeah, if you want pyglet to work without setuptools then what I'm
>> suggesting
>> isn't really an option.
>>
>> It is worth pointing out that even if pyglet had to be installed with
>> setuptools, you could still use virtualenv to have a separate checkout of
>> pyglet
>> for each project. But that adds boilerplate and probably isn't what you
>> want
>> for your projects.
>>
>> -Kale
>>
>> On 02/02/2017 12:05 AM, Benjamin Moran wrote:
>> > Thank you for the explaination Kale, I didn't fully understand what you
>> meant
>> > before.
>> >
>> > I'm not terribly familar with setuptools to be honest. My main concern
>> is that
>> > pyglet remains able to be run by dropping it's folder into a project,
>> and not be
>> > reliant on setup.py being run for installation. That's a pretty big
>> strength,
>> > and how I personally use pyglet in my projects.
>> >
>> > Other than that, I wonder what other codecs this could be useful for
>> down the road.
>> >
>> >
>> > On Wednesday, February 1, 2017 at 3:13:34 PM UTC+9, Kale Kundert wrote:
>> >
>> > What I was thinking was something like this:
>> >
>> > First, advertise a "pyglet.codecs" entry point in setup.py. List
>> all the
>> > codecs
>> > that are currently included with pyglet as entry points. This is
>> nice because
>> > first-party and third-party codecs will be handled in the same way:
>> >
>> > def setup(
>> > ...
>> > entry_points = {
>> > 'pyglet.codecs': [
>> > 'png = pyglet.image.codecs.png',
>> > ...
>> > ]
>> > }
>> > ...
>> > )
>> >
>> > Then, replace pyglet.image.codecs.add_default_image_codecs() with
>> something
>> > like
>> > this:
>> >
>> > def add_default_image_codecs():
>> > from pkg_resources import iter_entry_points
>> > for entry_point in
>> iter_entry_points(group='pyglet.codecs'):
>> > codec = entry_point.load()
>> > add_encoders(codec)
>> > add_decoders(codec)
>> >
>> > Now third-party modules can define custom codecs just by adding
>> entry-points to
>> > their own setup.py files:
>> >
>> > # Let's say this is the 'pyglet_aseprite_plugin' package...
>> > def setup(
>> > ...
>> > entry_points = {
>> > 'pyglet.codecs': [
>> > 'aseprite = pyglet_aseprite_plugin',
>> > ...
>> > ]
>> > }
>> > ...
>> > )
>> >
>> > All a hypothetical user has to do is:
>> >
>> > $ pip install pyglet_aseprite_plugin
>> >
>> > When add_default_image_codecs() is called, setuptools/pkg_resources
>> will
>> > tell it
>> > about every 'pyglet.codecs' entry point installed on that system,
>> no matter
>> > which package they come from. So first-party and third-party
>> codecs will get
>> > loaded in the same way. This wouldn't be a very big change to
>> pyglet all told,
>> > but it would be nice for plugin developers.
>> >
>> > The documentation for this stuff was annoyingly hard to find, so
>> here are some
>> > links if you want more information:
>> >
>> >
>> http://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins
>>
>> > <
>> http://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins>
>>
>>
>> >
>> >
>> >
>> http://setuptools.readthedocs.io/en/latest/pkg_resources.html#entry-points
>> > <
>> http://setuptools.readthedocs.io/en/latest/pkg_resources.html#entry-points>
>>
>> >
>> > I don't have any particular interest in aseprite, but I might be
>> able to make a
>> > pull request for the plugin architecture over the weekend if
>> there's
>> > interest in it.
>> >
>> > -Kale
>> >
>> > On 01/31/2017 05:20 AM, Benjamin Moran wrote:
>> > > I'm not quite sure how it could work. The decoders/encoders are
>> actually
>> > part of
>> > > the pyglet.image module. The pyglet.image.base basically scans in
>> all
>> > available
>> > > units from pyglet.image.codecs, depending on the platform. The
>> > pyglet.resource
>> > > module simply loads in whatever images the pyglet.image module
>> supports.
>> > >
>> > > So, to make this work, you would need to have something like
>> > > "pyglet.image.add_decoder", and then make sure you add your
>> decoders
>> > module in
>> > > before doing any pyglet.resource.reindex() calls. This all seems
>> a little
>> > > awkward to me, with the way things currently work.
>> > >
>> > > Maybe the image module could automatically check and load
>> applicable modules
>> > > from pyglet/image/codecs, without first having to define them in
>> > > pyglet.image.base. This would mean developers could just copy in
>> the
>> > appropriate
>> > > module to this directory in their codebase, This wouldn't really
>> work for
>> > > projects that install pyglet from pip, however.
>> > >
>> > >
>> > > On Tuesday, January 31, 2017 at 7:05:21 PM UTC+9, DXsmiley wrote:
>> > >
>> > > This sounds too niche to warrant including in pyglet itself.
>> > >
>> > > I think that Kale's point is interesting. Allowing
>> third-party modules to
>> > > add additional decoders to pyglet.resource could be useful.
>> > >
>> > > --
>> > > 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 pyglet-users...@googlegroups.com <javascript:>
>> > > To post to this group, send email to pyglet...@googlegroups.com
>> <javascript:>
>> > > <mailto:pyglet...@googlegroups.com <javascript:>>.
>> > > Visit this group at https://groups.google.com/group/pyglet-users
>> > <https://groups.google.com/group/pyglet-users>.
>> > > For more options, visit https://groups.google.com/d/optout
>> > <https://groups.google.com/d/optout>.
>> >
>> > --
>> > 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 pyglet-users...@googlegroups.com
>> > To post to this group, send email to pyglet...@googlegroups.com
>> > <mailto:pyglet...@googlegroups.com>.
>> > Visit this group at https://groups.google.com/group/pyglet-users.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>
--
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 pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
