Day 3 and first problems

Woodwolf on 2009/04/28 23:26 of Wood&Wolf

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)

Comments

richard on 2009/04/29 00:59:

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)

cyhawk on 2009/04/29 06:32:

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...

Woodwolf on 2009/04/29 13:00:

I'll try breaking the background into smaller pieces when I get home after work...

Woodwolf on 2009/04/29 16:49:

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!

cyhawk on 2009/04/29 23:03:

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
pyglet.gl.lib.errcheck = 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()!

richard on 2009/04/30 02:21:

python -O automatically turns off the debugging stuff in pyglet.

mespringfield on 2009/04/30 03:09:

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.

piman on 2009/04/30 04:04:

cyhawk, does reassigning errcheck like that actually do anything? From what I can tell, by the time you've imported pyglet.gl.lib to do the assignment, it's already decorated all the GL functions with the old errcheck.

cyhawk on 2009/04/30 07:30:

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 run_game.py 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 :).

jotham on 2009/04/30 12:18:

Keep us updated!