Box2D Forums

You need to create one revolute joint and anchor it to pf - as you have it now, it's the tips of those arrows that proj would be free to rotate around, but since you have two of those joints it's locking the body completely in place and there are no degrees of freedom left.

Problem is that if I create only one Revolute Joint the "proj" Body will rotate around the center of itself as soon as I attach a motor to the joint.

I want the proj item to balance like in the game "Tower Bloxx" ( http://www.youtube.com/watch?v=zVlprl42Zf8 )

You need to put the anchor point near pf, not proj.

Thank you Jordan for you help!

Used 1 RevolutJoint between pf and proj having the anchor point in the middle of pf, works great.

Now I am trying to understand motor torque, limits and motor speed.

Current code is:



corps have a density of 10.0f(explains why I have a motortorque so high), all bodies in the world have a friction of -100.0f.

How do I have to change speed and torque if I want to double the velocity? I've tried many values:
- speed 100 torque 200000
- speed 200 torque 100000
- speed 200 torque 200000

But it seems that I always get the same result.

Hello.

I'm planning to use JBox2D in a game where GCs should be avoided, so I'm planning to spend some time working on removing as many allocations from the library as I can. I see from the TODO.txt that some work has already been done on this, but my game makes heavy use of CCD, so I'm still seeing a lot of allocations.

I'd like to be able to contribute my modifications back to the project when I've finished, so I thought I'd come here and ask for some hints before I start.

In particular:

Would it make sense to add non-allocating versions of Vec2 and Mat22 methods (i.e. versions that take a destination parameter)?

Would it be acceptable to add private members to classes to be used as temporaries inside methods? If so, should these temporaries be shared between methods when possible to save space?

Thanks!

Private static members. The actionscript (also GC'd) port makes use of this a fair amount.
The rest sounds good, too.

Yes, that might be a good way to avoid having to explicitly inline everything, it's at least worth a shot. I believe I added a few local versions of Vec2 operators, but going further might be very worthwhile, as currently I think the Mat22 and XForm ops make up a decent proportion of allocations.

Absolutely. In a few cases I did this with static class variables as BorisTheBrave mentioned, but this can be a bit dangerous, esp. if anyone ever decides to try and do anything multithreaded (i.e. run more than one world at once or something like that), which is conceivable. But I wouldn't worry too much about that for now, nobody's really doing anything like that, and it's considered unsupported - IOW, I'd be perfectly happy to merge changes that relied on private statics, and I'd probably do them myself if I had the time.

In an ideal world, I'd love to get the Pyramid demo running with fewer than 10k Vec2 allocations per frame; that's going to be tough to achieve, but it would address the main speed concerns and allow JBox2d to run a lot better on constrained devices where GC is disproportionately expensive.

FWIW, the changes along these lines that I already made (over the last several versions) led to roughly a 100% speedup, so they are extremely valuable, and a fairly good use of optimization energy, esp. since in Java cache-focused optimizations are far less effective than in C++ (I did some tests on this, and the desktop JVM is actually amazingly smart about rearranging things in memory to optimize the hit rate, even if your algorithm doesn't make it easy - if you ever see an instance where Java code runs faster than the "same" C++ code, this is usually what's being exploited).

Thanks for the info guys. I'll report back when I have some results.

Interesting topic.
So far I am merely using the JBox2D code and not too much diving into it, but in approximately 2 months my application will be in a state where profiling and identitfying performance/memory bottle necks makes sense. Most likely this will result in some interesting information about the JBox2D performance and hopefully some optimizations which I would like to share with you.

However the use of private static members gives me headache because my application is multithreaded by running various Box2D worlds. So far this was no problem because every single world is updated/handled by only one thread. I don't know if this is an uncommon use of Box2D but I would most gently suggest that future optimizations still allow this configuration.

In that case I'll start out by inlining into local floats as much as possible. Maybe that will be sufficient, since it seems like Vec2 and Mat22 temporaries are the biggest problem (at least for my particular application).