Ulf Ekström wrote: >> I wrote a physics system using Numeric. It still wasn't fast enough. > > Do you know exactly what made it slow? Do you think it can be worked > around assuming we have fast vector operations? The way I wrote it, Numeric gave me the fast vector operations. It's in the cookbook if you want to see: http://www.pygame.org/wiki/2DGeometryEngine?parent=CookBook . Each point is stored in one big Numeric array, to which all operations are done at once. The problem with doing things that way is -- well, consider an if statement in Python. if Condition: return f(x) else: return g(x) In Numeric, the easiest way to do this is: f = ufuncs.sin(x) # or some other complicated operation g = ufuncs.cos(x) return choose(Condition, f, g) In other words, in Python you operate element-by-element and compute one or the other, but in Numeric you compute both options for all elements and pick one or the other for each element. I think that's probably why it was slow. I don't think you'll be able to get much better performance out of a pure-Python physics engine *especially* if you get fast vector operations -- the reason I tried this approach was because Greg Ewing pointed out (quite rightly, I think) that working element-at-a-time in Python is just not going to be fast enough. I also wrote a pure-Python element-by-element physics engine which was even slower than this, but I never tried using AABBs or other optimizations, so maybe you could do it if you really wanted to. I don't think it's worth it when ODE is out there, though. Ethan
Attachment:
signature.asc
Description: OpenPGP digital signature