Suggestions for (2D) simulation package

[HanFastolfe]

@ewjordan

(…) because in Box2d a lot of stuff needs to be done to get from a Shape object to the actual coordinates where the Shape should show up, since Shapes live on Bodys and need to be transformed before drawing.

(…) there are 10 methods to implement for each shape type, so it’s not trivial). We’ll see…if I find a bit of time, I may just bang it out and see how it goes.

I’m not sure about JBox2D, but I tried it for Phys2D (having the Shape interface extend java.awt.Shape etc), and it’s not that much extra work. The transformation before drawing needs to be done anyway, and my drawing code is a lot more concise than the custom drawing code - for example, you can use Java’s AffineTransform to do the transformation, and then just call Graphics2D.draw(Shape) to do the drawing.

I think you don’t need to implement the 10 methods for each Shape type yourself, you can just extend the Java classes. That’s the way I did it for Phys2D and it works fine so far.

@jezek2

I don’t think that it’s good idea, physics should be independent of graphics. (…)

Some things can be pretty easy to do but still wrong in bigger picture, also it’s not nice to make dependance on Java2D when user uses completely different library such as Slick or PulpCore.

I agree that physics should be independent of graphics. But a body needs to have a shape for the physics anyway, so whether it’s a Shape coded from scratch or a Shape that extends Java’s Shape doesn’t make much of a difference IMO. Also I think this doesn’t introduce a dependence on Java2D, it just gives you the option to use Java2D if you’d like. You can still use Slick (that’s what I might do eventually) since all the stuff that you implemented originally is still there. It just extends Java2D now.