@Nathan:
Yes, I know all about that common fix and it works just fine. But the
question is, is typing out this:
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
at the beginning of all your Pyglet programs really that easy and
intuitive? Shouldn't you just be able to load up your PNG and it shows
up the way you want it to? What if you hadn't noticed this snippet in
the tutorial code?
Something like displaying a transparent PNG on the screen should be
dead simple with no OpenGL (at the high level) involved.
@Richard
On Dec 7, 4:45 pm, Richard Jones <[EMAIL PROTECTED]> wrote:
> I am currently working on a sprite library for pyglet in contrib/spryte.
That's awesome. I would love to have a sprite module in Pyglet.
> ... and code is always welcome in an Open Source project written by
> volunteers :)
I absolutely agree. But only a chosen few volunteers have SVN commit
access.
> The alpha (transparency) channel from a PNG (or any other RGBA image) is
> handled appropriately by pyglet.image. The key is to then instruct OpenGL how
> to use that channel. There's dozens of operations that could potentially use
> it -- which one is correct for all users of pyglet? It's because of this that
> pyglet does not make any assumptions and does not enable any sort of
> alpha-channel processing by default.
Products that are easy and fun to use make assumptions:
Apple Inc includes a magnetic power cord connector on their MacBooks.
Don't want to pay for that? Too bad, the magnetic connector is useful
for a lot of clumsy people and it's now a standard hardware feature.
Apple makes an assumption that a lot of people are clumsy, and for
most people, this assumption is accurate and appreciated.
Ruby on Rails makes a lot of assumptions about what conceptual
framework you want to organize your web application with (MVC), where
you want your source files to go (models, views, controllers,
helpers), and what you want to name your classes and source files
(AdminController, admin_controller.rb). Through these assumptions/
conventions, Rails becomes an easy to use framework that has taken the
web by storm.
I believe that you and Alex intended pyglet to be a powerful, yet easy
and fun library that would showcase Python at it's best. Let's not get
caught up in analysis paralysis trying to be everything to everyone in
this simple use case (image alpha transparency). The GL_SRC_ALPHA
blend functionality works great in a simple, 2D, load up a PNG and
display it context. Let's build that functionality into the image.load
routine, or let's provide an optional argument in image.load that
enables transparency. I think something like this would be perfectly
reasonable:
img = image.load('my_image.png', alpha_blend_enabled = True)
Too many open source projects try to act like a swiss army knife.
Pyglet has a very nice and clean high-level API that is fun to work
with. Don't leave this one important use case in the ugly state that
it is now.
> The sprite library currently uses radians for rotation. I am on the fence
> regarding using degrees, as the code underneath will always be working with
> radians, and thus there's a fixed cost of conversion for each rotation API
> operation.
This is another example of making an assumption for common benefit.
MovieClips in Flash use degrees for their rotation property. The
Rabbyt sprite library (which works very well with Pygame) also uses
degrees for rotation. Why? Because degrees are a lot easier to
understand and work with than radians. Converting from degrees to
radians is easily implemented with math.radians, and I'm pretty sure
it's really fast too because the math module is written in C. If you
still can't bring yourself to make degrees the default unit, then
maybe you could provide an optional argument to the constructor:
my_sprite = spryte(use_radians = False)
and you could make your sprites easy to use for people who don't want
to work with radians (and I'm pretty sure that's not just me).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
