Box2D Forums

ItemBox.java
http://rafb.net/p/8hkhaW79.html

bindImage method in Item (ItemBox extends Item)


BoundImage.java
http://rafb.net/p/3KlFPk19.html

In the game's draw method I'm getting the list of bounded images and calling draw method on them.

Result obtained (with pos):

I would check the way you're creating your boxes - are the centers of the boxes located at (0,0) in body coordinates? There are two ways to create boxes, one by creating the polygon shape at (0,0), adding it to the body, and then moving the body to the desired world location, and the second by creating the box shape directly at the desired location without moving the body. While the physical results are the same, when you're binding images to bodies, the first approach is a bit easier to deal with - if you're using the second method, you'll have to adjust the offset that you're passing to that function to adjust appropriately (either by adding or subtracting the world coordinates of the box location, I forget which).

Thank you Ewjordan! Using first way of creating bodies solved my problem

I'm making some progress in my Vec2 optimization effort. The pyramid stress test demo is down from around 251000 Vec2 creations per frame to around 81000 (when the pyramid has finished building but hasn't gone to sleep yet), and there's still an awful lot left to do.

One problem I've run into is the SupportsGenericDistance interface:

I'd like to change the returned Vec2s into a destination parameter:

The problem is that (I think) that interface is a part of the public API that would be used by library users who are implementing their own Shapes. Should the JBox2D public API to be considered stable and unchangeable, or are modifications like that acceptable at the moment?

Thanks.

Implementing a new shape type cannot realistically be done external to the engine, and in fact, almost nothing within the JBox2d core can be extended by a user, so I wouldn't worry about it. Adding a new shape requires many internal modifications, and it's just not feasible for someone that doesn't want to hack the engine itself (you need new pairwise collision algorithms against everything else, TOI computations, and new contact types, for a start).

Re: why that stuff's not hidden if it's not meant to be accessible, some of it is laziness, where I haven't gone through and tightened up visibility where possible, but some of it really must be public because Java's package and visibility system is too weak to allow both sub-packages and proper encapsulation - it was a choice between dumping everything into one package (bad) and using package visibility instead of public (good), or organizing things in a more reasonable way and just exposing more fields. So we went with the latter; I'm not entirely happy with this, so it's possible I'll rework it the other way at some point to allow better control of visibility, but I'm not sure.

In any case, feel free to change the signatures on any of those troublesome Vec2 returning functions that don't seem like they'd be used by an average user (stuff that's called from Body or World is very user-facing, for instance, so should probably remain untouched) - the next full release of JBox2d will likely contain some breaking changes anyways, as Box2d has reworked almost all of the contact reporting details, so I'm not too concerned about a few functions that should have been package-private anyways changing signatures!

One of ten times(average) I will get a NullPointerException for this line:



from:


When I debug b and pd are never null..

It doesn't look like I'm going to be able to use JBox2D as I had intended, so I thought I'd post the optimizing work that I've done now anyway. The choices of things that are optimized are a bit haphazard and inconsistent, because I just followed the profiler and went for the things that were used most in my project. In the cases where the inlining severely reduces the readability of the code (i.e. almost all of them) I commented the original code with an "INLINED" marker. The patch is against SVN HEAD.

Thanks for doing all this, I just took a look through and tried running a few tests, and it's a significant speedup - the timing test speed shot from 250 fps to 450 fps (!) after applying your patch! That should give you an idea how much allocation/garbage/object overhead really matters if there's a lot of it, even on a desktop JVM!

Awesome job, and thanks for sharing the patch, this will definitely show up in the next update (I have to merge some changes that I've made). I'm sorry that this won't work out well for Android, perhaps at some point in the future we'll get to a fixed point version and then things may be more reasonable there - it's a platform I'm very interested in, so if it's feasible to convert to fixed point, I'll definitely give it a shot.

Just to be pro-actively passive aggressive...
I edited http://www.box2d.org/wiki/index.php?title=JBox2d so it mentions the steps needed to get rid of the unfunctioning Slick integration. Basic instructions like that should work without having to google for additional steps!

So I hacked together smashenfreude - viewtopic.php?f=6&t=3024 brutalizing the demo code.

So, is there a beautiful font of JBox2D documentation that I missed?
I'm tempted to try and make a "Cookbook" of some kind... so much of this thing was just hacked together from the demo code, I'd really like to get into building up, and understanding a higher % of what I was doing (like I spent 10-20 minutes trying to get arrows to point at blocks that were up off the screen, but I couldn't quite figure out the screen/world mapping)

Of course, reading the README, now I need to find out if I should be doing stuff in PulpCore or Slick instead of Processing all the time... any thoughts? (I think I'm look for the highest "cool well-documented features to download /jar size ratio")