On 21 October 2011 10:34, Gary Daniels <[email protected]> wrote:
> I am back at this and experimenting with using sprites for each tile.
Have you tried the cocos.tiles module?
> I am running some tests and have about 5k sprites on the screen. If
> they are static, I am getting around 500 fps. If I run through a tight
> loop and just increment their x coordinates, the fps drops down to
> about 30.
Depending on how you're doing things, this could be quite understandable.
If these 5000 sprites are moving every frame, are they perhaps
particles? There's an awesome particle library for Python called
lepton you should look at.
If, as I suspect, those 5000 sprites are just your tiles then I'm
afraid you're doing it wrong. You're already using OpenGL so don't
move the tiles, move the view.
The cocos.tiles implementation handles a scrolling map of very, very
large size with minimal performance requirements. Scrolling is handled
by simple OpenGL transforms (the tiles do not move, the view does) and
only the set of tiles required for the viewport are rendered (although
for small enough maps this doesn't actually improve performance).
> The C++ library I am testing uses a sprite class that has all the
> tiles in a single texture and you set the current frame then call
> sprite.draw(x,y) 5,000 times, rather than using 5k sprites. Is there a
> way to do something similar in pyglet?
Absolutely. Have your sprites share a batch (like the cocos.tiles
implementation does). It'll be faster than the C++ version because
there'll be a single OpenGL draw :-)
See the pyglet.sprite module documentation under the heading "Drawing
multiple sprites".
Richard
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en.
