LÖVE

How to make a rotating platform:

1. Create a world.
2. Create a body that acts as your platform.
3. Create an anchor for you platform.
4. Create a revolute joint connecting the anchor and platform.
5. Add shapes to your platform.

This turns into a mess when you reach upwards of 2 platforms.

How to make objects collide:

1. Set collision callbacks.
2. Set shape data for each shape you want to collide.
3. Use an if statement: if (shape1 = your first shape and shape2 = your second shape) OR if (shape1 = your second shape and shape2 = your first shape)
4. Figure out which bodies the shapes apply to so you can make them react properly.

No wonder why Tilt was such a glitchy mess.

Seriously, this is ridiculous. Can't you use some other, simpler physics engine?

I think this boils down to the fact that physics aren't simple. I believe (and this is my personal opinion) that all the physics engines will have more or less the same concepts.
Certainly Box2d has something to do with the "glitchiness"; the version used in LÖVE is outdated, and that shows sometimes.

The "messiness", on the other hand, is ... likely not Box2D's fault. I hope you don't take this the wrong way - writing clean code is very difficult.

Unfortunately, physics are a very, very messy thing... If you want something cleaner, it may be a good idea to brew up your own nonrealistic physics engine, or to use one someone else has already made like Fizz or Hardon Collider.

I agree with kikito, physics is complicated. To makes things easier for myself, I wrote the PhysicalEntity and PhysicalWorld classes (part of my personal framework); they make life much easier for me.

Box2D certainly has a number of quirks, like needing the delta time it gets to be limited (although you'll find that problem no matter where you do physics).

Taehl wrote:If you want something cleaner, it may be a good idea to brew up your own nonrealistic physics engine, or to use one someone else has already made like Fizz or Hardon Collider.

Just for clarification, Hardon Collider only deals with collision, not resolution.

This sounds like an opportunity for another library

It may be true that physics tend to be complicated, and writing clean code may be hard, but I feel like Box2D makes things a lot more verbose and painful than they need to be. It pretty much forces you to have huge amounts of code. Since shapes are independent from bodies, that pretty much guarantees that you're going to have lots of tables and for loops, especially in collisions. Also, in collisions, you have to specify either order of the shapes colliding. And we can't just have bodies collide, we have to have shapes collide. So you have to write extra code to figure out which one's the right body.

If I could use some more lightweight library for Tilt, I would, but I don't know of anything else that would give me nice realistic physics. Does anyone have experience with some other engine like Chipmunk Physics? I'm not sure there's a Lua binding for that one, but I may as well know if it's good before I bother looking.

Also, BlackBullet, I'll look at your scripts there.

Tesselode wrote:So you have to write extra code to figure out which one's the right body.

Shape:getBody?

Tesselode wrote:It may be true that physics tend to be complicated, and writing clean code may be hard, but I feel like Box2D makes things a lot more verbose and painful than they need to be. It pretty much forces you to have huge amounts of code. Since shapes are independent from bodies, that pretty much guarantees that you're going to have lots of tables and for loops, especially in collisions. Also, in collisions, you have to specify either order of the shapes colliding. And we can't just have bodies collide, we have to have shapes collide. So you have to write extra code to figure out which one's the right body.

Well that's always the way it is with anything in the programming world: doing more stuff for you makes it easier, but more restrictive. For example, machine code does nothing for you, allowing you to do anything, but at the cost of making it near impossible to code in. While on the other hand, something more higher level like Lua, does more for you, meaning it's more restrictive, but so much easier.

If we didn't have separate shapes in Box2D, the types of collision you could do would be very limited: the most complex collision you could do is an eight point polygon. However, because shapes are separate, we have multiple shapes attached to one body, allowing for much more complex shapes of objects. For example, we could make the shape of a human out of many polygons.

Tesselode wrote:Also, BlackBullet, I'll look at your scripts there.

Cool. You'll need to adapt them to suit your needs of course, unless you want to use the framework's Entity/World structure.

Tesselode wrote:1. Create a world.
2. Create a body that acts as your platform.
3. Create an anchor for you platform.
4. Create a revolute joint connecting the anchor and platform.
5. Add shapes to your platform.

I don't understand why you have to use joints in this case.
I assume your platforms are not moving so you can just create static shapes (whose density/mass is 0).
Static shapes remain stationary even after a collision.

Tesselode wrote:1. Set collision callbacks.
2. Set shape data for each shape you want to collide.
3. Use an if statement: if (shape1 = your first shape and shape2 = your second shape) OR if (shape1 = your second shape and shape2 = your first shape)
4. Figure out which bodies the shapes apply to so you can make them react properly.

Step 2 is optional.
Regarding steps 3 and 4: maybe you can have general shape 'types'

Tesselode wrote:Seriously, this is ridiculous. Can't you use some other, simpler physics engine?

Box2D is a pretty good engine.
Stick with it man, and you'll learn how it works.

BlackBulletIV wrote:However, because shapes are separate, we have multiple shapes attached to one body, allowing for much more complex shapes of objects. For example, we could make the shape of a human out of many polygons.

Yes, this is correct.
Suppose each shape had the properties of a body (velocity/angle, damping etc)
What would happen if you attached 2 shapes together and (for example) you want to move them together to the left.
At what point would you apply an impulse/force?
1.To prevent resulting torque you would have to manually calculate the center of mass of the 2 shapes that you have attached together.
2.What would be the magnitude of force/impulse that you are going apply? You would have to manually calculate the magnitude based on the masses of the two shapes.
Basically the body class saves you this and many similar headaches.