This site requires JavaScript, please enable it in your browser!
Greenfoot back

Report as inappropriate.

RcCookie presents ...



This is a Greenfoot version of the well-known 2d physics engine "Box2D" by Erin Catto. More specificly this is actually a port from "JBox2D", a java port for the Box2D engine which is written in C++.

> Box2D website:
> JBox2D website:

Box2D features precise collisions for any convex chaped polygon, circles and more. Additionally it fearures joints like springs. Most importantly though: Its performance is incredible.
Note that due to its independent nature Box2D can't draw its shapes so that is something you will have to do. It's not hard though.

What I actually did is simply move some folders and creating some helping classes that simplify the structure to create and work with the engine.
You can easily reuse these classes and the whole engine in your scenarios by copying the "org", the "rccookie" folder and the license file over into your scenario's folder.

Below you find a simple demo showing of some simple parts of the Box2D engine. Left-click to add circles, which can be adjusted using the ui. Middle-cling to add boxes and right-click to add static walls.

2283 views / 990 in the last 7 days

7 votes | 1 in the last 7 days

Tags: mouse game simulation physics demo with-source collision engine box2d

This scenario is a member of: Reusable classes

open in greenfoot
Your browser does not support the canvas tag.


Second: Yes. Computer physics are inaccurate, especially game physics. They are also very inconsistent. They are approximating, because they calculate physics in frames, which is a lazy way of creating a decent looking result. But as they use frames, a falling object really doesn’t follow a curve, it moves step by step in straight lines. The shorter the steps, the more accurate, but it’s never gonna be perfect. Also (most, not all) physics engines adopt their framerate to the performance of the computer their running on, so a better system will be able to push out more frames that therefore calculate a smaller timestep. That makes them more accurate for a moment, but very inconsistent over multiple runs. To create a REALLY realistic physics engine, you should base it on these two aspects: 1.: Use functions. In physics, there’s a function for basically anything, especially in simple mechanics. If you want to solve a physics problem, you just need to find the matching formula. This formula may consist of multiple formulas combined, but there will always be one. So all you need to do is find the formula that describes your game’s physics problem and that only requires the parameter t (time). Once you have that all you need to do is inserting the time since simulation start, and you will get the exact result at any point in time (in theory even before t=0). So essentially you calculate everything once and then simple request the state at a specific moment in time over and over again. It’s formula nature actually somewhat similar to a neural network. The problem comes in if you consider input. Input does something unexpected, and therefore changes the formula, so it has to be recreated. On a simple game like the ones on Greenfoot this may not be a huge problem, because pressing the arrow button or not might be the only thing to care about. But if you for example consider a racing sim, with a steering wheel as input, you have to recalculate every time you update the input, and that ain’t be good for your cpu. 2.: Deformation Even if you don’t want to base your physics on atoms flying around, deformation is a key to any collision physics, even if you don’t want permanent damage. That’s because objects actually don’t bounce. What actually happens is that the object compresses during collision, and then expands pushing itself away, creating a bounce „illusion“. As long as you don’t simulate that, you lack two things: The fact that the objects actually touch for some time and not just a moment during collision, which is core for friction, and that bouncing many objects in a small place will make them bounce to much and freak out. This physics approach is actually taken in BeamNG, which is why I was mentioning it. However the scale is still way to low if you want realistic physics. So - this is obviously not really doable. The second point is also just another place where you really just need to go into smaller and smaller scales to create the most realistic result. And for the first point: I haven’t ever seen any program that actually uses this approach, but to me it seems like the only real option. If you don’t have any input and just want to simulate a predefined scenario, this may actually be possible, however the formula to simulate many interfering collisions will be incredibly huge. For anything else though I fear we will have to wait for better computers.
Yes, I have studied a little and I know how physics is done. I do physics with formulas, without deformation, so it's easier. I translate to pixels only when moving, and then, this ratio can be changed. When I was talking about physics with rotation, I wanted to talk about the second scenario. I just found a rough way to do it. I thought you did it too and I wanted to see your version)
But it is unlikely that I will implement it, because I decided to do another project. Maybe someday, when there's time)


I‘d be interested to see that. Also I‘m currently working on some proper colliders that allow circles and squares
I saw) Good luck!
I think I'll leave the other projects for now and make a small physical project. In general, there is a bit of code.
Although, probably, I will still leave this project for later))) Is there any way I can contact you without using Greenfoot? For example, via Gmail.



But don't publish it
OK, thanks

See all comments

Want to leave a comment? You must first log in.

Who likes this?

LIU-25535 Game/maniac CmogSmok Just_in Awesome_Gabe Kostya20052011 Roshan123