Box2D Forums

Okay, here's a topic to discuss Java versions of Box2d. I saw that quixote_arg was planning to do a Java port, so maybe we can split up some of the work.

First, though, best to figure out some nuts and bolts, and decide how exactly to move this from C++ to Java.

From a quick look through the code, I would say about 95% of the engine appears to be almost trivial to translate, meaning that a Java analogue exists and is pretty obvious (class/struct -> class, pointer -> reference, find/replace "->" with ".", textually resolve all typedef stuff, make sure all bit-fiddling matches with Java's type sizes, etc.). I didn't see too much function pointer or macro shenanigans, which is good because that doesn't translate too well. Just be on the lookout for any pointer arithmetic, because you don't want to accidentally try to increment the pointed at variable when you're just supposed to be traversing an array or something like that.

But the allocation/deallocation stuff is too low level to use as written. I'm a little torn as to what to do here, as it seems to be a pretty important piece of code in the C++ version - do we just punt and leave it up to the JVM to decide what to do to deal with all the small objects, or do we try to come up with a Java specific solution? To some extent the need for this type of stuff in C++ is that the usual malloc implementation is slow because it's not highly optimized for small objects; Java is _supposed_ to be better for these (I recall reading somewhere that these allocations tend to happen in just a couple machine instructions in the JVM, compared to several dozen from your usual malloc, mainly because the garbage collection allows the JVM to organize its memory space so that it's real simple to dole out new chunks), so maybe it's not such an issue. Then again, Java has historically had issues with object creation overhead, and though Sun always claims this type of problem should magically disappear because their JIT compiler is so fabulous, I've definitely had programs that were bound by the creation overhead of vectors (as in, the programs ran slow until I inlined all the vector ops by hand, then they became fast...). Phys2d hit some pretty fantastic amounts of new object creation (I've seen it go up to over 100,000 vector constructions per frame, and on my computer that's about the limit of new objects per frame I can create without affecting frame rate, even with no additional logic involved), so this is probably something worth thinking about. We could do something like use a temp pool for throwaway vectors and matrices, and only create new ones if we need them to last past the function call. Stuff like this always irks me, though, because under reasonable programming assumptions it should always be better to declare something locally than globally if that's how you're using it, but I suppose reality trumps logic in the end...in theory Java should be better about this stuff if the JVM actually uses escape analysis like they claim it will (or does? I'm not sure, I'm on a Mac so it's a bit different for me as I won't get 1.6 'til the next version of OSX comes out), but I'm always skeptical when it comes to promises of performance increases "real soon" in Java...

What I'm thinking is that first we should attempt to get things running without trying to trick Java into doing anything special with memory, and then we can see if we need something more subtle. I guess what that means is translating the calls to the block allocator into something more standard - any ideas on the simplest approach?

quixote_arg, how far along are you in your translation? I was going to start from scratch, but if you've already gotten up and running I have no need to reinvent the wheel, so I'd be willing to help out as long as the ultimate product will be under zlib or a similar free license. I might branch off at some point, as one of my ultimate goals is to get a simple rigid body physics library for Processing, which means making a bunch of default choices and wrapping/simplifying the API a bit (to the point where programming newbies can use it easily, which is kind of the goal of the Processing project), as well as plugging in some default drawing code and stuff. But step one is definitely just getting it working in Java, so...

I guess I'm about 50%-60%, just copy-pasting and making necessary syntactic changes for the code to compile

roadmap is

1) make it compile
2) make it work (ie the demos)
3) make it fast

The object allocation I assume is because every time the original code does



every + or - internally is creating a new vector with the addition or substraction, on step 3 (make it fast) I think this can be optimized quite a bit, for instance in this trivial example, two temporary vectors are created but it suffices to create only one

I've no problems at all with the license (be it zlib, bsd or whatever). I'm going to create a sourceforge project, if you are interested, I can give you SVN access

Right, that's fundamentally the problem with temp objects in Java. I've been looking into this more lately, and the guys "in the know" absolutely insist that despite what anyone might think, it's better to write that vector addition the way you've written it than any other way. My skepticism noted, I suppose this is more a matter of testing in the live application than anything else - a major problem with Java performance testing is that due to the way the modern JVMs work, there's no practical way to accurately benchmark these things other than writing them into a full application and seeing which version runs faster.

Anyhow, the practical issue is how or whether to translate b2BlockAllocator and b2StackAllocator. As I read through them, it became apparent that there's absolutely no Java version of most of what they do; our hands are tied and we just need to use "new." As I'm translating, I'm leaving out any reference to either class until/unless it becomes clear that I actually need them.

Turns out I'm also about 50% through the code, also in the "make it compile" stage, and I just started work a couple days ago. So maybe the thing to do at this point is just to muscle through and try to get this compiling individually, and compare notes at that point, as it may take longer to synchronize our work now than it would be to just push through (I didn't realize how quickly most of this translation would go), especially since there are a lot of choices that have to be made to match up across files, etc. to get to the compile point.

BTW, I'd add one more task to that list, to be completed after everything else:

4) make it Java

Even once translated, from the API point of view a lot of things about this code are very transparently not conceived in Java, and that might confuse end users. But I'd worry about that after everything else, because it's style more than substance.

Erin, a question for you came up as I was going through the code - any chance you shed some light on what this userData stuff is? It's one of the params in BroadPhase::Query(), and it's a void*, so in Java I turned it into a generic Object, but I see it being cast, for instance, to b2Shape (in b2World::Query() ), and I couldn't find any obvious reason that this should be a legit cast (not done with the code yet, of course). I initially assumed it was a void* so that the user can put whatever he'd like in it, but that must not be the case; perhaps you can enlighten me on where this fits in overall?

b2BroadPhase is written as a generic broadphase. So it needs to handle unknown user data on the proxies. See the broad phase test in the test-bed.

b2Shapes create proxies and attach the shape pointer as user data.

mmmh... I think this item better be in third place, and "make it fast" the fourth

On my porting, I always removed the allocators. Maybe in the make it fast phase, but now the priority is "make it compile"

I've also read that "object pools" are less effective than just letting the JVM create new objects.

The JBox2D project is being evaluated in sourceforge.

I don't totally agree that merging projects today isn't the best choice... at least, I would like to take a peek at your code, mine is yours if you want to look

Oh, I didn't mean to suggest that we not merge projects - I think that's probably a very good idea, and I'm all for it. All I mean is that we shouldn't stop translating in favor of figuring out how to get our code to interoperate at the moment, since that might be a bit tricky. I'm not at my computer with all my files right now, but when I get a chance I'll upload what I've got. Definitely let me know when the sf project gets approved, that might be a good time to start merging in earnest. I'm still in the blind-translate phase, as in, I'm not even trying to get these to compile until I get everything looking like Java syntactically.

BTW, have you decided what Java version you'd like to target? If we do 1.5+ we can use static imports which will make a lot of the math stuff a whole lot easier (we can write, for instance, add(a,b) instead of b2Math.add(a,b) each time a b2Math function is used). Of course, if you've already been qualifying all calls (I've been trying to, at least for now), I don't think there's much in here that couldn't work with even 1.1, especially since the containers are all hand-rolled. In the "Make it Java" step we might do well to replace some of the containers with Java's versions, since Sun's versions can do all sorts of optimizations under the hood that we could never achieve from the outside.

Sourceforge is up!
http://sourceforge.net/projects/jbox2d/

I've already commited the code I have so far in the SVN repository.

I'm doing it Java 1.5+, with the upcoming consumer JRE everything is going to be easier.

Checkout the code and keep in touch!

Wow, you've gotten quite far! I just checked out from SVN, and I'm looking through right now. It actually looks like you have done most of the stuff that I haven't and vice versa, so this would be a perfect time to condense. At this point I've got almost complete translations of just about everything except for the contact and joints folders; you seem to have those, which is awesome.

I've used some slightly different conventions than you have, but it's mostly just naming differences and some function differences in the math library - nothing too major.

Can you add me to the SF project so I can upload what I've got so far? [my user name there is also ewjordan] I'm going to do a pass through what we each have side by side; you might want to do the same when you get a chance. At that point we can decide whether to take yours or mine as the starting point; based on a two minute scan, yours looks pretty good, it appears that you've Java-ized things more completely than I have (I've just been ripping through the code doing syntax translation, not worrying about organizing it yet, and putting off any sort of refactoring that would need to be done, for example, to get rid of int pointers that are indirected and altered within a function), so I'm totally fine with taking your code as the base. Where there are holes/differences/bugs, we can examine both and resolve as necessary, perhaps deciding file-by-file or function-by-function whether yours or mine is closer to "right."

We can either continue the discussion here or at Sourceforge, whichever you'd (or Erin would, for that matter) prefer. Talk to you soon, hopefully we can get this thing compiling over the next few days! [then we'll need to discuss doing the TestBed, which will have to be quite different from the C++ version - an applet that did everything the TestBed program does would be great to have, I think]

I already added you to the project on sourceforge.
At the begging I translated some arrays into lists and stuff like that, but then I just started to translate the code as it was (it was then when I decided the three steps ). When a demo works, even at 1 FPS, then will be the time to start making a refactory and optimizations.

Okay, I committed the files that I did to SVN, take a look, particularly at anything you weren't able to get to. I just made an ewjordan directory to put mine in, we can get rid of that once we get everything merged. I still haven't had a chance to go through side by side, but hopefully tomorrow at some point I will.

Just realized, I have copies of all the files in there, even the ones I didn't work on yet - those contain the raw .cpp and .h files. Just be aware, some of them haven't been touched at all (I think mostly the stuff in the contacts/joints directories, and the last part of BroadPhase...I think I got most of everything else, though).