So here's the situation - let's say I'm loading a gigantic sprite with
pyglet.resource.image (not pyglet.resource.texture, which wouldn't
have this problem). That returns a pyglet texture whose target is
GL_TEXTURE_RECTANGLE_ARB or GL_TEXTURE_RECTANGLE_NV. I've been getting
a cryptic 'Invalid operation' from any OpenGL operation performed
after rabbyt.Sprite.render(), and after digging around I realized that
the cSprite's _render() function assumes that it gets a GL_TEXTURE_2D
and binds the texture that way. Now I've gotten a workaround for it
glPushMatrix()
if self.texture.target !=
GL_TEXTURE_2D:
glEnable
(self.texture.target)
glBindTexture(self.texture.target,
self.texture.id)
self.texture_id = 0
else:
self.texture_id =
self.texture.id
glTranslate(0, 0, self.z)
rabbyt.Sprite.render
(self)
glPopMatrix()
if self.texture.target != GL_TEXTURE_2D:
glDisable(self.texture.target)
Which is kind of iffy. But it works, so I'm not gonna complain for
now :)
What I'm after is making it less iffy - this could turn into more of a
pyglet question than a rabbyt one at this stage. What can I do to
ensure that pyglet loads rabbyt-friendly textures? (I've loaded images
with pyglet.resource.image(xxx, False), which shouldn't do anything
new since the default argument for the 'load ARB rectangle extension'
parameter is False, and, uh it didn't do anything new. So much for
superstition). Or would this best be solved at the rabbyt level -
making render() more flexible in terms of its targets? That would be
up to you, of course.
I realize that a quick way to uniffyfy the code is to have a state
flag instead of setting texture_id each render(), and I'll get to it
as soon as I hack together the bookkeeping.
MWM
On Dec 28, 11:06 pm, Matthew Marshall <matt...@matthewmarshall.org>
wrote:
No pressure. I'm just saying that if modifying rabbyt is the easiest/
best way to get what you need, go for it :-)