I don't know what your problem is, but I can give you some tutorials which run perfectly fast. They're in Python/PyOpenGL/Pygame, so they're somewhat related. Sorry I can't do more to help:
http://www.pygame.org/gamelets/games/nehe1-10.zip
G
Slowness with pyopengl
try running the interpreter with -O to turn error checking off, it's what sped up the lighting example for me.
Author
The wierd thing is that the nehe tutorials run just fine. I can't figure out what i'm doing wrong though. The only difference I see is that the nehe Tutorial does not glBindTexture every frame. This is probably what is making it slow, but how do I use many different textures at once, without doing that? Help!
Without seeing your complete code it's impossible to tell where the problem lies. The code you posted seems ok and i can't reproduce any slowdowns on my end. I highly doubt calling glBindTexture each frame will induce any significant drops in performance, unless you'd be calling it for each polygon, and even then it's unlikely.
Quote:Original post by NIm
Ahl: My understanding is that I am using PyGame to get a window and load stuff, etc, and opengl to draw things in the window. I believe that ogl completely commandeers the window, so that pygame's drawing functions do not function correctly at all(lotsa segfaults) I'm not sure what's meant by "using OGL directly" all my drawing code is openGL, but I do use pygame to summon a window and talk to it.
What I mean by using OGL directly is you're whether you're importing the OpenGL functions directly or using a 3rd party API to do it. I recently started using pyglet (www.pyglet.org, you should check it out) and it seems to perform a LOT better then pygame.
I could definitely see why glBindTexture every polygon every frame would slow you down. Is there a reason you're doing this instead of just declaring it all in your display lists?
Changing the size of the window or of the rendered items is the quickest way to check if you are fillrate limited ;)
What video card do you have? It is highly likely that this is the case here, *especially* if you have blending enabled. This is definitely the case with lower-end video cards like the Geforce x300 series, or anything made by Intel. Try resizing your window to make sure. If this makes a difference, you've (probably) found the problem.
(As you found out, the scale does not make any difference to performance - only the number of rendered pixels (including overdraw) affect fillrate).
One more thing to keep in mind, is that glBindTextures is one of the slowest OpenGL calls there are. Keeping it inside a display list should help (if the driver is intelligent), but trying to minimize glBindTextures calls, by sorting objects by texture will help more.
Last, but not least, the choice of bindings *does* make a difference, but only in call performance. Calling native code from a non-native language (like C# or python) generally incurs a set, small, but not insignificant overhead. This is definitely not the case here, as you are issuing only 1 call (glCallList), but it's something to keep in mind for better performance (rule of thumb: try to keep OpenGL calls between 300-500 per frame).
EDIT:
Ok, is the texture mode set to GL_REPEAT? I've seen significant slowdowns on repeating textures with high repeat counts (something like [0.0, 100.0] on texcoords, to repeat 100 times).
What video card do you have? It is highly likely that this is the case here, *especially* if you have blending enabled. This is definitely the case with lower-end video cards like the Geforce x300 series, or anything made by Intel. Try resizing your window to make sure. If this makes a difference, you've (probably) found the problem.
(As you found out, the scale does not make any difference to performance - only the number of rendered pixels (including overdraw) affect fillrate).
One more thing to keep in mind, is that glBindTextures is one of the slowest OpenGL calls there are. Keeping it inside a display list should help (if the driver is intelligent), but trying to minimize glBindTextures calls, by sorting objects by texture will help more.
Last, but not least, the choice of bindings *does* make a difference, but only in call performance. Calling native code from a non-native language (like C# or python) generally incurs a set, small, but not insignificant overhead. This is definitely not the case here, as you are issuing only 1 call (glCallList), but it's something to keep in mind for better performance (rule of thumb: try to keep OpenGL calls between 300-500 per frame).
EDIT:
Ok, is the texture mode set to GL_REPEAT? I've seen significant slowdowns on repeating textures with high repeat counts (something like [0.0, 100.0] on texcoords, to repeat 100 times).
Author
Hmmm... No GLREPEAT. I only have ONE textured polygon, with ONE texture on it. I'd like to know more about glBindTexture. I also call it at the beginning of other draw functions to reset the texture to the default(my other draw things are just colored polygons). Could that be the problem?
I'm getting rid of the display list for now, to simplify things. It's an optimization, and I shouldn't need it yet.
Could you explain more about fill rate limiting? I can play FPS games fine, and the nehe turoials use 1% cpu. Clearly, there is some wayu around fillrate limiting. What could it be?
I don't think this is the problem: the shrunk asteroid was about 20 pixelsx 20 pixes, and it was still pretty slow.
EDIT: It probably is a fillrate limitation. Messing with the onscreen size seems to indicate that framerate is about inversely proportional to number of drawn pixels. Could it have somehting to do with the format of the image? I have my image laoding code listed. The file is a .tif Should I use a different format?
[Edited by - NIm on February 19, 2008 8:24:36 AM]
I'm getting rid of the display list for now, to simplify things. It's an optimization, and I shouldn't need it yet.
Could you explain more about fill rate limiting? I can play FPS games fine, and the nehe turoials use 1% cpu. Clearly, there is some wayu around fillrate limiting. What could it be?
I don't think this is the problem: the shrunk asteroid was about 20 pixelsx 20 pixes, and it was still pretty slow.
EDIT: It probably is a fillrate limitation. Messing with the onscreen size seems to indicate that framerate is about inversely proportional to number of drawn pixels. Could it have somehting to do with the format of the image? I have my image laoding code listed. The file is a .tif Should I use a different format?
[Edited by - NIm on February 19, 2008 8:24:36 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
