Day 3 and first problems

I just don't know what's happening. If I draw a 800x600 background image and the grass blades, the FPS counter goes down to 15. It's just that combination. If I just draw the grass or I just draw the background, I get more than 30fps.

All that while the player and more than 50 bugs move around. But it has nothing to do with them!

Player+bugs+background -> 30fps.
Player+bugs+grass -> 30fps
Player+bugs+background+grass -> 15fps 8(

I've fighting all day against that. There's something in pyglet batches and OpenGL that I just don't get. GRRRR!

Nothing much was accomplished today :(

(log in to comment)


Check your image sizes - some graphics cards can really slow down if the images (textures) are too big (>1024 in either dimension, or in really bad cases perhaps >512)
My CPU does not take my Pyglet sprites lightly either. Interestingly Python.exe now goes around 68% which I thought impossible on a dual-core CPU until now (Pyglet can utilize a second core somehow?). This after coding in D + Derelict in the weeks before, where no matter how many sprites I drew I could not get over 2% CPU...
I'll try breaking the background into smaller pieces when I get home after work...
No way. It seems that pyglet does not like the draw batch - draw opengl triangles - draw batch. I fear we won't have a background image, I'm wasting way too much time with that!
I hit the 100% CPU and had to do some profiling. It was surprisingly easy to see that even though I set pyglet.options['debug_gl'] = False about 40% of the CPU time was spent in errcheck(). So I do this now:
import pyglet
pyglet.options['debug_gl'] = False 
def zero_errcheck( result, func, arguments ):
	return result = zero_errcheck
This gives very good speeds, try it!

PS: Also make sure you set window.invalid = False in on_draw() and True in update()!

python -O automatically turns off the debugging stuff in pyglet.
It's amazing what a difference using python -O makes. My game was running about 14 fps, but when I used python -O the frame rate jumped to around 35 fps.
cyhawk, does reassigning errcheck like that actually do anything? From what I can tell, by the time you've imported to do the assignment, it's already decorated all the GL functions with the old errcheck.
piman: I'm not sure about it anymore. I tried python -O and now I can not get back to the old CPU-hungry behavior. I've tried deleting all .pyo files in pyglet and the game, but no matter what I do it only eats up around 25% when the CPU is limited to 1 GHz...

Is there a way to turn on -O from the code? Or some way to force the user to use it? I should probably change to start with

#! /usr/bin/env python -O

But that does not solve it on Windows.

I'll investigate this further after PyWeek, but I've got so much to do now :).

Keep us updated!