On Aug 24, 5:02 am, René Dudfield <[email protected]> wrote: > hi, > > Javascript in chrome is very fast and optimized. > > Python is very slow in comparison... the python developers haven't > really sped it up enough (yet). However I think, and hope that it > will get better soon. > > Have you tried using psyco? That generally speeds up particle > systems. > > Psyco version 2.0 is out recently which is better than the old > 1.6.http://groups.google.com/group/comp.lang.python.announce/browse_threa... > however the webpage hasn't been updated properly to say it exists, or > that it's hosted on a different svn. > > A pygame sprite demo in software gets 47fps with 1000 sprites on my > laptop, with psyco. Without it, it gets 22fps or so. > python -m pygame.examples.testsprite -psyco -FastRenderGroup 1000 > > I had good luck with a numpy based particle system. Note, use v1.3 > since before that there are bugs which make writing particle systems > harder (records don't work as well). > > GPU particle systems are the way to go for best speed of course... in > which case you'll be using GLSL/etc instead, not javascript or python.
using psyco's profiler breaks pyglet and disallows input. but i already had psyco built into it. like i said, it only took about .001-. 0005 seconds for it to calculate everything (for 60FPS 1/60=.016 seconds) so the main thing slowing it down is rendering not calculations. On Aug 24, 5:05 am, Florian Bösch <[email protected]> wrote: > On Aug 24, 5:07 am, mclovin <[email protected]> wrote: > > Anyways, I am just horribly dissappointed by Pyglet. I used it for > > > about a year and always just excused some of its performance lags > > because it was a scripting language. but a scripting language in a > > browser kicks Pyglet's *$$ > > It's not pyglets fault really. > 1) ctypes FFI calls are slow > 2) Chrome JS isn't really a "script" language, it gets compiled down > to x86/x64 machine code > > However, 7500 particles is not so much. Doing the draw loop in C I get > to 20'000 particles @ 60FPS. Seehttp://codeflow.org/particles.tgz, > which in essence is > > void quad_draw(Quad* quad){ > glPushMatrix(); > glTranslatef(quad->x, quad->y, 0); > glRotatef(quad->rotation, 0, 0, 1); > glScalef(quad->size, quad->size, 0); > glBegin(GL_QUADS); > glTexCoord2i(0, 0); > glVertex2i(0, 0); > glTexCoord2i(1, 0); > glVertex2i(1, 0); > glTexCoord2i(1, 1); > glVertex2i(1, 1); > glTexCoord2i(0, 1); > glVertex2i(0, 1); > glEnd(); > glPopMatrix(); > > } > > over and over again. wow, i actually didnt know that at all. I guess now i learned why some javascript behaves differently in V8 than in FF. but yeah, i just thought that using HTML5 and canvas would be logically slower. When you think about it, It has all the DOM overhead, and i dont know how they draw the canvas but i would assume which ever way they draw it would have been slower --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
