ok, physics explanation please!

[hertzcastle]

hi!
im very, very new to love.physics.
read the tutorial, so i know how to use all the actual physics, but i don't understand how im supposed to figure out whats collided with what.
so, say ive got a few sprites, just two tables with and image and a body each, in my collision callback how can i decipher which sprite has been hit so i can do something with that sprite?? is there a way to set the name of a body?
thanks!x

[Robin]

Ok, first: do you understand the difference between Bodies, Shapes and Images? I'm not sure from your question, and it is pretty important that you do.

Second: I think you are looking for Shape:setData(), which you can retrieve in the collision callback with Shape:getData()

[hertzcastle]

ahhhhhhhhhhhhhhhh, now i get it!!!
yea, i understand the whole attach shape to body, draw image at body x,y, now i understand how it all fits together!!
cheers again mate, i owe you one, well, two now actually!!!

[hertzcastle]

ok, ran into another problem: none of the collisions work!!!
the bodies run fine(i even checked to see if they were colliding with getX, getY), im not getting any errors with the shapes and ive followed the collision callbacks perfectly.
only problem could be with the oop side of things, so, is this a legal way of adding a shape to a body(just gonna paste the class constructor in here)

Code: Select all

metaStar = {}
function metaStar:make(vx, vy, vdx, vdy, vs)
	local o = {}
	setmetatable(o, metaStar)
	self.__index = self
	o.name = "star"
	o.rect = metaRect.make(vx - 2, vy - 2, 4, 4)
	o.offRect = metaRect.make(vx - 2, vy - 2, 4, 4)
	o.body = love.physics.newBody(World, vx, vy, 0, 0)
	o.shape = love.physics.newCircleShape(o.body, 0, 0, 8)
	o.lFade = {}
	o.offX = 0
	o.offY = 0
	o.iso = false
	o.dx = vdx
	o.dy = vdy
	o.s = vs
	o.r = 0
	o.fade = 0
	return n
end

dont worry bout the other vars, but the shape should work right?

[hertzcastle]

at the end it returns o not n, but yea, same prob!x

[The Burrito]

Yes, that should work just fine, I've done plenty of similar things.

as far as the collisions not registering, the data you set with setData will be passed to the functions as the first 2 arguements

example:

Code: Select all

 someshape = <shape function>
someshape:setData('datas!')
world:setCallbacks(myfunc,nil,nil,nil)
--------------------------------------------------------------------------------------------------------
function myfunc(a,b,c)
if a == 'datas!' then
<whatever happens when someshape hits something>
end
end

a and b are the setData for the 2 shapes. c is collision data of some sort iirc.

Also depending on what your doing, collisions can fail, generally if shapes are moving too fast setting them as bullets fixes that.
If you are creating and destroying shapes a lot collision errors will generally occur, and physics call backs will not work if there is no state change (like if you create an object exactly resting on another, the callbacks will not always be called)

[hertzcastle]

ah cheers mate, i was using :getData() on the collision function arguments!
thanks for clearing that up for me!

[hertzcastle]

btw, when does everyone get slowdown from the love.physics? I'm in the process of rewriting my projects physics from a simple rectIntersect() system and it would really help to know if there are any pitfalls because my project relies a lot on shapes and collision.
thanks everyone!x

[The Burrito]

Box2D is pretty fast, dozens of bodies and creating / destroying things every frame and my stuff still runs at over 100fps on my netbook.

Things I've learned:
- Box2D popups are errors, not crashes. If you click ignore generally your game will continue to run. The most common causes I've come across are shapes being too small, shape's vertices being passed out of order, and trying to act on things that are out of range (out of the world).

- If its possible for things to fall out of your levels, don't forget that they are not gone, they just stick to the edge of the world in sleep mode, this is wasted memory, destroy them.

- Applying forces over several frames is directly affected by frame rate, decouple this by multiplying the values by dt.

- Sometimes collision detection is crappy, I replaced my "foot" shape for jumpable detection with a system that iterates through the objects one could potentially jump off of and testPoints a "foot" coordinate. I'm sure its slower, but its more reliable for my purposes, may not matter for you.