It's just that the object is sliding for too long, even though it should stop. Perhaps you should make the coefficient of friction more.

Like I said in the description, this isn't actually created by myself. It is using the jbox2D library, which is a java conversion for the box2D library, and that is used for a lot of mobile games. All I did was creating some utilities to use it in Greenfoot

Well, as if yes...but your objects can't rotate, the world becomes not very plausible, I thought sooner or later you will add this feature.

So: In THIS scenario, objects do rotate from a collision, but you cannot see it with the circles. If you use the right and middle mouse button you can spawn static and physical squares, they will show you. In my other physics engine scenario this is not the case. That’s because this scenario right here uses the jBox2D library, an open source physics library you can get online. In my other scenario the physics engine is 100% coded by myself - but doesn’t support rotations from collisions. I’m somewhat working on this, but it’s a LOT harder to create these effects. That’s because for non-rotation physics you can simply assume that the collision force is being put onto the center of the object. Collisions that create rotations exist because the force is being put at an offset to the center of mass on the object. Then you need to split the force into some part that moves the object, and some that rotates it, and I couldn’t find anything even close to a formula for that. Additionally, once an object is rotating, this also has to be taken into consideration when it collides again.

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)

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.