GBox2D

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.