Two Pyglet Nitpicks
brian.grogan.jr
big way. I really wish that alpha transparent blitting and 2D rotation
were built into the high-level image API. I use these two features
extensively in my 2D game prototypes, and it is very annoying not to
have them readily available through an argument to a method call.
I have seen a number of other posts in pyglet-users asking about alpha
transparency and rotation, and I think it's not really enough to tell
them to use the OpenGL functions to get the effects. These basic
effects should be built into the high-level API. I strongly feel that
it should not be necessary to "drop down" to OpenGL for these two very
common use cases. The mental context switch from nice pythonic Pyglet
to C-based OpenGL is jarring and unnecessary.
I know that Pyglet 1.0 is now in beta and feature frozen. I agree that
the focus for the beta should be working out the bugs to get it ready
for a final release. But the two issues I mention above should be a
major consideration for 1.1.
Pygame has alpha (and colorkey) transparent blitting through the
Surface object, and rotation through the transform module. Pyglet
should probably support these features in a different way.
I think one convenient and non-disruptive (to the current API) way of
supporting alpha transparency is to give PNG images alpha transparency
by default (if there is an alpha layer present). The most common use
case I've seen is to create a transparent PNG in GIMP, load it into
Pyglet, and then exclaim "WTF?!" when it doesn't show transparency.
Transparency based on file type given to image.load would go a long
way towards making Pyglet more fun to use.
I think rotation should be handled by adding a "rotation" optional
argument to AbstractImage.blit (for example: img.blit(x=50, y=100,
rotation=45). And rotation should be in degrees.
In my opinion, these two very simple changes would make Pyglet much
easier and more logical for me as well as a number of other users
(especially beginners). I am working on a patch right now to add these
features in to Pyglet 1.1. If anyone else has some suggestions about
these issues or any other personal nitpicks, I would love to hear them.
Nathan
> I have seen a number of other posts in pyglet-users asking about alpha
> transparency and rotation, and I think it's not really enough to tell
> them to use the OpenGL functions to get the effects. These basic
> effects should be built into the high-level API. I strongly feel that
> it should not be necessary to "drop down" to OpenGL for these two very
> common use cases. The mental context switch from nice pythonic Pyglet
> to C-based OpenGL is jarring and unnecessary.
My transparent .png's work great with pyglet.image.load() and img.blit()
I did have to include the following two lines for the transparency to
start working (I noticed them in one of the pyglet tutorial code
snippets):
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
Then, after that, all my .png images showed their transparency properly.
~ Nathan
Richard Jones
> Pyglet is a great library but two little details bother me in a very
> big way. I really wish that alpha transparent blitting and 2D rotation
> were built into the high-level image API.
I am currently working on a sprite library for pyglet in contrib/spryte. It's
in early stages yet (the API may change.) The intention is that it is capable
of blended blitting, rotation, animation, scaling, tile mapping, picking and
collision detection. It can actually most of that right now, but as I said
the code is quite young. It also depends on the experimental buffer
interface, and i can't vouch for the status of that (except that it's in
the "experimental" folder :)
> I have seen a number of other posts in pyglet-users asking about alpha
> transparency and rotation, and I think it's not really enough to tell
> them to use the OpenGL functions to get the effects. These basic
> effects should be built into the high-level API. I strongly feel that
> it should not be necessary to "drop down" to OpenGL for these two very
> common use cases. The mental context switch from nice pythonic Pyglet
> to C-based OpenGL is jarring and unnecessary.
Alex and I happen to share your view, which is a happy coincidence ;)
... and code is always welcome in an Open Source project written by
volunteers :)
> I think one convenient and non-disruptive (to the current API) way of
> supporting alpha transparency is to give PNG images alpha transparency
> by default (if there is an alpha layer present).
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.
> And rotation should be in degrees.
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.
Richard
brian.grogan.jr
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 <r1chardj0...@gmail.com> wrote:
> I am currently working on a sprite library for pyglet in contrib/spryte.
> ... and code is always welcome in an Open Source project written by volunteers :)
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.
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.
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).
Nathan
> @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?
Heh, well for a beta, I don't mind much at all. I've gotten more help
from the pyglet docs and this mailing list in the last two weeks than
I have from the pygame and its documentation in two years. Not to
mention that no one on pygame cared whether I could get it working or
not on OS X AND there hasn't been a release of any kind for 2.5 years.
I respect Phil Hassey, but so far my pyglet experience has been like
heaven in comparison to pygame. Fixes in SVN in a matter of hours or
minutes? Cool! No external dependencies that I have to install?
Cool! It uses OpenGL instead of SDL? Cool! It works on OS X
Leopard? Cool!
It appears (now maybe I'm reading this wrong -- no offense intended)
that you are arguing from a position that the pyglet mainainers have
finalized everything and they're never going to change anything. I
doubt that's the case. You'd probably get more traction if you posed
your feature requests as suggestions instead of rants. (Or maybe I'm
just misreading your tone. It's notoriously difficult to pinpoint the
tone someone is using when you are not used to their writing style)
Richard already stated that he and Alex agree with you. (I'm assuming
Richard is one of the pyglet devs?) With that in mind, good
implementation suggestions or patches will get you what you want
quicker than trying to convince the rest of us on the list. By the
way, I made the 2-line suggestion thinking to help you get your
program working, not because I'm advocating it as the best way to do
things. I happen to agree with the point you're trying to make (easy
access to common features without directly touching OpenGL).
> > ... 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.
So "svn diff" and submit the patch! The turnaround times on this list
have been amazing! If it's commit access you're looking for, you'll
be more likely to get it by systematically submitting useful
contributions.
I've been very pleased with my pyglet experience so far and plan to
convert my pygame projects to use pyglet ASAP. Thanks all!!! Two of
my friends and my brother have all started using pyglet because they
liked it so much when I showed it to them. If pyglet were a public
company, I'd buy stock. :-)
~ Nathan
Andre Roberge
> If pyglet were a public
> company, I'd buy stock. :-)
>
Me too!!!
André
> ~ Nathan
>
> >
>
Alex Holkner
>
> On Dec 7, 2007 7:57 PM, Nathan <nathan...@gmail.com> wrote:
>
> > If pyglet were a public
> > company, I'd buy stock. :-)
> >
> Me too!!!
Ok, you guys know that there isn't a business case in pyglet, right? :-)
On the image.blit suggestions: the alpha blend mode is a global OpenGL
state, not a texture parameter, so it doesn't make a lot of sense to
specify it during loading. It could easily be added as a parameter to
the blit method, however. Rotation could also be added as a parameter
to blit.
One problem with adding alpha/rotation to blit is that they would only
be applicable when blitting images to a framebuffer; however the same
blit method can currently be used between (almost) any two images
(framebuffer, texture, image data).
I should also point out that the blit method isn't really a high level
interface, so much as a convenient method to use while the "real" high
level interfaces are developed (see for example Richard's sprite
work). Besides being limited in its use, it's also extremely
inefficient compared to what's possible with a more game-oriented
design.
The goals of this 1.0 release are to abstract away the platform and
ctypes issues -- most of the higher-level ideas that require only
straight Python code were pushed back for future versions. Some of
these ideas exist in the experimental and contrib folders of the SVN
repository; others are just design outlines in mine and Richard's
heads :-)
Cheers
Alex.
brian.grogan.jr
framing my little nitpicks as just two small suggestions. But then I
got emotional. Sorry, guys.
I really, really like pyglet. It is now one of my favorite libraries.
The abstractions that Alex and Richard have come up with are seriously
helpful, clean, and powerful. I used to think that SDL made game
development easy. Pyglet is at least twice as better. And Pygame is
dead to me.
I guess I just felt momentarily frustrated because there are so many
nice examples of Pyglet being a great API except for these two little
spots (at least for me). I'm coding up a little Pyglet project, but
then I forget exactly what to type in to enable transparency, or I
need to simply rotate an object around its center by 30 degrees, and
I'm dumped back into raw OpenGL land. It's just this little problem
that breaks the generally wonderful pyglet experience, and it made me
upset.
I think I'm also a little confused about where the appropriate place
is to send feature adding patches or "experimental" code. I think the
issue tracker is reserved for bug fixing. So where or who should I
send more experimental ideas to? Taking up a page on the group space
for a small new library feature seems silly. If you guys have a
suggestion for that, I'm listening.
Oh yeah, and if Pyglet were a public company or any other sort of
commercial venture, I'd buy stock too. I love pyglet!
Alex Holkner
> I think I'm also a little confused about where the appropriate place
> is to send feature adding patches or "experimental" code. I think the
> issue tracker is reserved for bug fixing. So where or who should I
> send more experimental ideas to? Taking up a page on the group space
> for a small new library feature seems silly. If you guys have a
> suggestion for that, I'm listening.
For small things like this, you can add a comment to the wishlist page
at http://code.google.com/p/pyglet/wiki/ReleaseSchedule -- this
ensures it doesn't get missed when making future design decisions.
Anything bigger, especially if you have a patch or working code, can
rightly deserve its own page in the group, I don't see any reason why
we should save space on Google's servers :-)
Cheers
Alex.
mmarshall
> The Rabbyt sprite library (which works very well with Pygame)
only 3 parts that use pygame:
1) rabbyt.init_display function
2) Loading a texture from filename in the Sprite class.
3) fonts module
(1) is just a convenience method, and is hardly more convenient than
pyglet's method. (Just set up your window with pyglet and
(optionally) call rabbyt.set_default_attribs() to enable blending and
set the OpenGL texture method.)
(2) is only for passing a filename to the Sprite class to load the
texture. You can just as well pass the texture id. (image.texture.id
in pyglet.) There is also a function you can use to replace the
function used to load the texture, so you can change it to use pyglet.
(3) is only useful if you're using pygame anyways, as pyglet itself
has better font rendering. (This is just a small, pure python module
anyways. I'll probably remove it from my next major release.)
MWM
Alex Holkner
> (2) is only for passing a filename to the Sprite class to load the
> texture. You can just as well pass the texture id. (image.texture.id
> in pyglet.)
There is a bit of a gotcha here: if the pyglet Texture object gets
garbage collected the corresponding OpenGL texture will be deleted.
This can happen if you're only keeping track of the texture.id,
instead of the whole texture object -- so make sure you're careful to
retain the texture objects you'll be using within rabbyt; or go with
Matthew's other suggestion of replacing the load function.
Alex.
brian.grogan.jr
Speak of the devil, it's the author of Rabbyt! I'm a fan of your
library. I just don't really like Pygame anymore now that I've been
tempted by Pyglet. : )
I was under the impression that Rabbyt was kind of tightly integrated
with Pygame, and in a way, it seems like it still is. If you could
provide some more convenient ways of integrating with Pyglet in the
next version, I probably wouldn't have anything to complain about
anymore. It seems like you have a solid understanding of the whole
"ease of use" concept. Case in point, the sprite rotation property is
in degrees, the scale property is a simple float, and the lerp
function is a straightforward, but powerful concept. Not all of us
have our calculators in radians mode, and I think you're one of the
few who truly gets that.
If you could put in some work integrating Rabbyt with Pyglet, I think
it would be a match made in heaven. Just look at the name! Oh and by
the way, I'm seriously thinking of using your Tygger name suggestion
for my upcoming Pyglet-integrated physics library.
Luke Paireepinart
mmarshall
> @Matthew
>
> Speak of the devil, it's the author of Rabbyt! I'm a fan of your
> library. I just don't really like Pygame anymore now that I've been
> tempted by Pyglet. : )
> I was under the impression that Rabbyt was kind of tightly integrated
> with Pygame, and in a way, it seems like it still is.
didn't have a release when I started. (I know, pyglet has had a
release for a while now... I've been a little slow.)
And I think that rabbyt.init_display() sends a wrong impression. I
should have named it 'init_pygame_display' or left it out entirely.
The pygame-specific fonts module should have never been included.
> If you could
> provide some more convenient ways of integrating with Pyglet in the
> next version, I probably wouldn't have anything to complain about
> anymore.
would like?
> It seems like you have a solid understanding of the whole
> "ease of use" concept. Case in point, the sprite rotation property is
> in degrees, the scale property is a simple float, and the lerp
> function is a straightforward, but powerful concept. Not all of us
> have our calculators in radians mode, and I think you're one of the
> few who truly gets that.
MWM
brian.grogan.jr
Rabbyt, Tygger, and Wynnye would make quite the impression on the
Python community based on clever naming alone.
Although, I'm not sure if there's much room for a sound library
extension for Pyglet. Pyglet already has some sweet functions for
playing sounds and music, and it continues to get better with every
new release. If you can think of any useful higher-level abstractions
over what Pyglet already provides, I would fully endorse the idea.
Winnie was kind of ... simple-minded? So maybe Wynnye could be an
ironically named AI library instead.
brian.grogan.jr
in.
Pygame is a sinking ship. It was based on a hacky premise to begin
with, thinly wrapping over SDL with sometimes a higher level
interface, sometimes not. And now it seems like the primary Pygame
developers have totally lost momentum and inspiration.
Pyglet is pure Python, based on one of the finest modules to come out
of the Python community, ctypes, which is now built into Python 2.5.
Pyglet has incredible momentum! In another year or two, Pyglet will be
the game development library featured on the front page of python.org,
not Pygame. Although I think having an Apress book about Pyglet would
help the cause. Alex or Richard, are you guys much into writing?
> And I think that rabbyt.init_display() sends a wrong impression. I should have named it 'init_pygame_display' or left it out entirely.
not that familiar with the internals of Rabbyt, but is there a
particularly important reason why you have that function in the first
place? It seems sort of redundant, or unnecessary. Same goes for the
fonts module you included. Are you writing a sprite library or a font/
text rendering library? Focus!
> I just added support for using pyglet textures. Anything else you would like?
my big time nitpick with Rabbyt is that creating a Sprite object
should be just as convenient with Pyglet as it is with Pygame. I
should be able to pass in the name string of a PNG, and get a fully
functional Sprite with nothing else to worry about, just like you can
with Pygame right now.
> If degrees are good enough for glRotatef, they're good enough for me!
Matthew Marshall
> > I've been slowly moving to Pyglet as well :)
>
> Well what are you waiting for? Pyglet is great! The water's fine. Jump
> in.
hehe. By 'slowly' I mean that everything new that I write is using pyglet.
But other things that have been in development for a while that still use
pygame for display and events. (My plan is to move them to pyglet; it just
hasn't happened yet.)
> > And I think that rabbyt.init_display() sends a wrong impression. I should
> > have named it 'init_pygame_display' or left it out entirely.
>
> It does because it calls to mind the Pygame way of doing things. I'm
> not that familiar with the internals of Rabbyt, but is there a
> particularly important reason why you have that function in the first
> place? It seems sort of redundant, or unnecessary.
I wanted it to be possible to use rabbyt without an opengl wrapper. (I was a
little frustrated with PyOpenGL at the time.) Originally it handled setting
the viewport and default opengl attributes, but now it just saves four lines
of boilerplate :P Yeah, it needs to be deprecated.
> Same goes for the fonts module you included. Are you writing a sprite
> library or a font/text rendering library? Focus!
That was due to needing... uh... font sprites... Yeah, I don't have much of
an excuse here. It should have been an example for the vertexarray module.
(Which I'll be removing as well...)
> > I just added support for using pyglet textures. Anything else you would
> > like?
>
> I'll get back to you with a little more detail on that, but for now,
> my big time nitpick with Rabbyt is that creating a Sprite object
> should be just as convenient with Pyglet as it is with Pygame. I
> should be able to pass in the name string of a PNG, and get a fully
> functional Sprite with nothing else to worry about, just like you can
> with Pygame right now.
Wish granted :) It'll automatically use pyglet if pyglet is importable and
pyglet.gl.get_current_context() does not return None.
MWM
brian.grogan.jr
wrote:
> pyglet.gl.get_current_context() does not return None.
think Rabbyt could be really useful for Pyglet users. I just
downloaded the latest repository from your site with Mercurial. I'll
let you know what I think of the new pyglet-integration features.
Preferably in that new message thread you created so that I can put
this one to rest.