tartley on 2010/08/04 22:58:

Also, if you have performance problems, you need a profiler!

Run your game using the standard library profiler, using:

$ python -O -m cProfile -o profile.out GAME.py

This will spit out a profile.out file when you exit. You can manually look at the contents of this (there are modules in the standard library to help you analyse it), but FAR easier and quicker is to run 'RunSnakeRun' on it:

$ runsnake profile.out

RunSnakeRun produces a GUI with a visualisation of how long each function takes to run, which is super useful for quickly spotting where all the time goes.

You can 'easy_install RunSnakeRun', but it requires that you have wxPython installed, which I think needs manual installation, from:
http://www.wxpython.org/download.php#binaries

You might also have to 'easy_install SquareMap', I'm not sure.

Best regards,

  Jonathan

Akake on 2010/08/04 23:57:

Martin:

It happens with all of the Pyglet apps I've tried except those using Squirtle. Squirtle-based apps run just fine, but those using bitmaps run at a crawl.

The Tetrico demo in Cocos2D runs at a good clip, though, but that's the only non-Squirtle app I've found that runs well.

tartley:

I'll try that next time I use Pyglet or Cocos2D. (I'm still undecided about what to use, to be honest...)

Akake on 2010/08/05 02:42:

Erm... I apologize for the absolutes in my earlier response...

I was really stressed out when I wrote that, and responded kind of dumbly.

I went back through some code I had and found that some things I thought were Pygame-based were actually Pyglet-based. (I guess I'd already decided that Pyglet was slow and gave up...)

I've seen lines calling 'glEnable()' in those examples. (The ones that work well) Could this be what I'm overlooking? If so, where can I find docs about it and related functions? (The Pyglet API doesn't cover them...)
I'm sorry if this is common knowledge, but I'm really in the dark. I'd appreciate some direction.

claxo on 2010/08/05 08:04:

@akake: you can look most gl* functions in the red book
http://www.glprogramming.com/red/        (online)
or get the downloadable html version from
http://fly.cc.fer.hr/~unreal/theredbook/theredbook.zip
This is about openGL 1.1 , which is understood by any hardware.
 
About performance:
Most pyglet - cocos games runs ok in a 2004 vintage machine (gforce 6200).
Specific hardware can have problem with specific openGL calls. Intel video hardware is notorious for that.

In cocos using

cocos.director.director.init()

and having at least one node scheduling itself (with schedule, not schedule_interval) is fine.

This translates to pyglet.window.Window(vsync=True) , and schedule at least one function with
pyglet.clock.schedule(callback, *args, **kwargs)

The callback will be called once per frame.

richard on 2010/08/06 07:07:

I'd suggest trying to work within the cocos framework before diving out into more complex things. Just:


import cocos
from cocos.director import director


# ask the director to initialise the window
director.init()


# create a scene with a kitten picture
scene = cocos.scene.Scene()
sprite = cocos.sprite.Sprite('kitten.jpg')
scene.add(sprite)


# run our scene
director.run(scene)

and then maybe throw in an animation:


import cocos
from cocos import actions
from cocos.director import director


# ask the director to initialise the window
director.init()


# create a scene with a kitten picture
scene = cocos.scene.Scene()
layer = cocos.layer.Layer()
scene.add(layer)
sprite = cocos.sprite.Sprite('kitten.jpg', anchor=(0,0))
layer.add(sprite)


# move the kitten 100 pixels along x (to the right)
sprite.do(actions.MoveBy((100, 0)))


# run our scene
director.run(scene)

Those bits of code are from the Introduction To Game Programming tutorial I presented at EuroPython.