Some comments/ideas: Instead of a copy-paste of the pymunk implementation of pymunk.Space.step and other methods why not call it directly? That way there's less chance of anything breaking with a new pymunk version and it will be more DRY :) Im more fond of composing over inheritance and then you wouldnt end up with this problem at all, but that's a different matter.
If the actual translate calculation is expensive you might try to move it into a vertex shader that moves the vertices based on the position/angle. I suspect that its not the case and that the expensive part of that function is to read out the values from pymunk (meaning it goes through ctypes into Chipmunk). But that should be easy to test. If Im wrong and its the actual calculation then it might be possible to also keep all the vertices between each frame and only update some kind of shader data array each frame. Im not an openGL expert so Im a little bit unsure of what is possible and if there would be any speedup. Anyway, cool videos! /Victor Den onsdagen den 15:e maj 2013 kl. 01:50:45 UTC+2 skrev elliot: > > Hello, > > I wrote the first part of a tutorial on integrating pyglet, pymunk, Numpy > and OpenCV. Any feedback would be appreciated. > > The tutorial is here: > http://pyratesarecool.appspot.com/Integrating_Pyglet_and_Pymunk > > -videos- > part 1: http://vimeo.com/65989831 <https://vimeo.com/65989831> > part 2: http://vimeo.com/64970859 <https://vimeo.com/64970859> > part 3: http://vimeo.com/65915091 <https://vimeo.com/65915091> > > > In case you don't end up reading it but have some insight, the bottleneck > in my code right now is translating the dynamic vertices and updating > batches. I have 300+ polygons that are updated every frame, having > their vertices rotated and translated. This runs at 60 fps on my not so > great laptop. Am I doing the best I can? > > The update function is only this: > > def translate(self): > px,py = self.body.position > theta = self.body.angle > initiald = self.initial_data > cost, sint = cos(theta), sin(theta) > #Just a bunch of multiplication and addition, optimized > pts = > [(px+x+r*(xhelper*(cost-1)-sint*yhelper),py+y+r*(yhelper*(cost-1)+sint*xhelper)) > for x,y,r,xhelper,yhelper in initiald] > #flatten and assign as tuple to batch vertices > self.vertlist.vertices = tuple(map(int,[val for subl in pts for val > in subl])) > > > > ncalls tottime percall cumtime percall filename:lineno(function) > 1 0.019 0.019 49.193 49.193 poly_demo.py:1(<module>) > ... > 1911 0.035 0.000 44.047 0.023 poly_demo.py:122(on_draw) > 1911 3.940 0.002 42.308 0.022 entities.py:12(step) > 620979 2.838 0.000 37.946 0.000 entities.py:268(update) > > > So this function takes up 86% of my run time. The second to last line > takes up 2/3 of that, and the last line 1/3. > > > Thanks everyone, > Elliot > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
