Fizzy - A wrapper around JBox2D

Engines, Libraries and Tools
#1

I’m putting together a simple wrapper library for JBox2D (it’s awesome) that attempts to make it a bit easier to use (a-la Phys2D). So far it simply supports bodies with compound shapes and some basic physics but the code does end up looking pretty simple:


World world = new World();
		
Body body = new Body(new Circle(10.0f), 0, 0);
world.add(body);
Body floor = new Body(new Rectangle(200.0f, 10.0f), 0, -50.0f, true);
world.add(floor);
		
world.addListener(new WorldListener() {
    @Override
    public void collided(CollisionEvent event) {
        System.out.println("Collision");
    }

    @Override
    public void separated(CollisionEvent event) {
        System.out.println("Separate");
    }
});

for (int i=0;i<4000;i++) {
   world.update(0.01f);
}

If anyone’s interested the code is available here: https://bob.newdawnsoftware.com/repos/slick/trunk/fizzy/

And there’s an initial jar here: http://www.cokeandcode.com/fizzy/demo/fizzy.jar

And there’s rather an indulgent logo that I did because I like logos:

Comments appreciated,

Kev

#2

Brilliant! - a proper wrapper is something that’s been on my JBox2d todo list for a long time, I started one for Processing, but never quite got around to finishing it up. Box2d is great, but it doesn’t make much of an effort to make simple things easy to do, and due to time constraints I was never able to move very far away from a strict function-by-function port of the C++, so JBox2d inherited all that complexity.

Great job, I think this will be extremely useful!

Out of curiosity, what license is this under? I’m thinking that a lot of this could be very useful within the Processing wrapper.

#3

My normal license, I don’t really care what you do with it :slight_smile: Lets call it BSD.

Kev

#4

I was thinking of making a similar wrapper like this in Objective-C. I may just use your project as a model. :slight_smile:

#5

How about a high level wrapper for the Box2D native wrapper in libgdx? :slight_smile:

#6

All sounds good to me! :slight_smile: I’m going to carry on using it for a few demos and add features are they actually become something that is in the 95% of cases category.

Currently debating whether I should provide “cut throughs” so you access the JBox2D data model at your own risk should you feel the need (or should you need an detailed feature of the library). Seems like a good idea but the focus is not confusing developers so um, ar, um ar… :slight_smile:

Kev

#7

really cool library, thx. We finally now have a library that has best of both worlds (performance and clean api).

Odd, kind of defeats the point, if someone needs that can’t they just use the JBox2D library directly?

#8

Yeah, sorta agree. But I also know that there will always be some features that won’t get exposed by an abstract high level API. So you could be using it for 90% of your game then realise you want to set some value on the underlying body that Fizzy doesn’t show you.

It’s similar to Slick letting you drill through and play with OpenGL state as much as you like at your own risk.

Kev

#9

You should absolutely provide access to JBox2D. Just give every Fizzy object a method with an annoying name, not a getter (to prevent autocompletion displaying it).

Something like: Body body = fizzyBody.backing();

Or not.