I'm on a Macbook Pro with a GeForce 8600M GT. Textures are loaded with
GL_LINEAR. Here's the texture loading code:
# Create an OpenGL texture with it and place it in the system
glEnable(GL_TEXTURE_2D)
rgbadata = pygame.image.tostring(image, "RGBA", True)
texture = glGenTextures(1)
glBindTexture(GL_TEXTURE_2D, texture)
glTexImage2D(GL_TEXTURE_2D, 0, 4, w, h, 0, GL_RGBA,
GL_UNSIGNED_BYTE, rgbadata)
glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
Casey Duncan has pretty much confirmed my suspicions. I guess I'll end
up creating a sprite class that uses vertex arrays or vertex buffer
objects and presses all the animation frames I need into one texture
at loading time. Then I'll use a texture map array to move the texture
around so that each sprite can animate independently.
Thanks for your help. If anyone else has any design patterns I might
find useful, let me know. I'm very new to OpenGL and most tutorials
teach you how to get things done, but never the proper way.
-Zack
On Feb 26, 2009, at 2:23 PM, RB[0] wrote:
Hmm, how are you loading your textures - GL_NEAREST or are you using
LINEAR or Mip mapped filtering?
Otherwise, only thing I can think of is you might have a cruddy card
that is dumping some odd functionality to your cpu instead of gpu?
On Thu, Feb 26, 2009 at 1:17 PM, Zack Schilling <zack.schill...@gmail.com
> wrote:
That was the first thing I tried. Using a dummy draw function that
crunched a few numbers instead of doing the OpenGL calls. That
worked fine and let me create thousands and thousands of sprites
before the CPU tapped out.
No I'm not using psyco or any other performance enhancer.
-Zack
On Feb 26, 2009, at 2:08 PM, RB[0] wrote:
Well, most likely your main speed down is looping through all those
sprites as it is - trying just looping through them and calling a
dummy function instead of the opengl one - and see what happens -
otherwise, that seems quite odd to me, I haven't run into that
before (are you using psyco, perhaps?)
On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling <zack.schill...@gmail.com
> wrote:
I know the PyOpenGL mailing list might be a better place to ask this
question, but I've had a lot of luck talking to the experienced
people here so I figured I'd try it first.
I'm trying to migrate a game I created from using the Pygame / SDL
software rendering to OpenGL. Before attempting the massive and
complex conversion involved with moving the whole game, I decided to
make a little test program while I learned OpenGL.
In this test, I set up OpenGL to work in 2D and began loading images
into texture objects and drawing textured quads as sprites. I
created a little glSprite class to handle the drawing and
translation. At first its draw routine looked like this:
glPushMatrix()
glTranslate(self.positionx,self.positiony,0)
glBindTexture(GL_TEXTURE_2D, self.texture)
glBegin(GL_QUADS)
glTexCoord2f(0, 1)
glVertex2f(0, 0)
glTexCoord2f(1, 1)
glVertex2f(w, 0)
glTexCoord2f(1, 0)
glVertex2f(w, h)
glTexCoord2f(0, 0)
glVertex2f(0, h)
glEnd()
glPopMatrix()
Note: self.texture is a texture ID of a loaded OpenGL texture
object. My sprite class keeps a dictionary cache and only loads the
sprite's image into a texture if it needs to.
I'd get maybe 200 identical sprites (same texture) onscreen and my
CPU would hit 100% load from Python execution. I looked into what
could be causing this and found out that it's probably function call
overhead. That's 14 external library function calls per sprite draw.
The next thing I tried was to create a display list at each sprite's
initialization. Then my code looked like this:
glPushMatrix()
glTranslate(self.positionx,self.positiony,0)
glCallList(self.displist)
glPopMatrix()
Well, that's nice, down to 4 calls per draw. I was able to push ~500
sprites per frame using this method before the CPU tapped out. I
need more speed than this. My game logic uses 30-40% of the CPU
alone and I'd like to push at least 1000 sprites. What can I do?
I've looked into passing sprites as a matrix with vertex arrays, but
forming a proper vertex array with numpy can sometimes be more
trouble than it's worth. Plus, I can't swap out textures easily mid-
draw, so it makes things much more complex than the simple way I'm
doing things now.
Is there any design pattern I could follow that will get me more
speed without sending me off the deep end with complexity.
Thanks,
Zack