Simple, lightweight, general purpose collision detection

[Kadoba]

Wow good stuff. This blows what I was making out of the water.

[vrld]

Are the separation parameters in the callbacks the components of the result?

The separation parameters form the shortest direction and magnitude you have to move one of the shapes (which one is not easily determined at the moment, but that's on the TODO list) so that the shapes do not collide anymore.
So your persist callback could look like this:

Code: Select all

function callback_persist(dt, a,b, dx,dy)
    a:move(dx,dy) -- push a out of b
end

or like this, if you want to push both shapes equally:

Code: Select all

function callback_persist(dt, a,b, dx,dy)
    a:move( dx/2,  dy/2)
    b:move(-dx/2, -dy/2)
end

If you have multiple shapes that collide with each other, that approach won't work very well however.

This blows what I was making out of the water.

Maybe we could somehow merge your lib into this one? I am especially curious about the pre-defined responses and additions to vectors.

[Taehl]

Here's what comes to my mind when I hear "simple, general-purpose". It obviously needs some refinements, but... Is this the right direction?

[Robin]

Here's what comes to my mind when I hear "simple, general-purpose". It obviously needs some refinements, but... Is this the right direction?

It could be… they sure have the shakies and if dt gets too large they fall through.

[vrld]

It will be horribly slow once you have a lot of objects, since you are testing every dynamic object against every other object.
Was "simple" to mean simple to use or as not having a lot code?

[Robin]

It will be horribly slow once you have a lot of objects, since you are testing every dynamic object against every other object.

Using quadtrees and whatnot could help.

Was "simple" to mean simple to use or as not having a lot code?

Not sure what other people want, but in my mind it should be the former: something any beginning lover can plug in their game and expect it to Just Work.

[Kadoba]

Maybe we could somehow merge your lib into this one? I am especially curious about the pre-defined responses and additions to vectors.

That could work but our approaches were a lot different. Mine might be better suited for simpler games so I think I'm going to go ahead and finish it. Of course when that happens you're free to rip whatever functionality you like.

When you define callback functions in geo you pass a function to the system for each collision pair rather than overloading a single function. It currently looks like:

Code: Select all

system.callbacks["fireball"]["enemy"] = function(fb, en) en.hp = en.hp - fb.damage end

So you still have to handle the responses manually. However the plan is that some predefined ones will be available for commonly used responses. Like right now I'm working on Push, which pushes one body out of another in a specified direction or if you don't specify a direction it will push the body out in the direction from the centers

Code: Select all

-- pushes player out of an object in whatever direction it can from
system.callbacks["player"]["object"] = Push

-- pushes player "up" out of the ground.
system.callbacks["player"]["ground"] = function(plyr, grd) Push(plyr, grd, Vect:new(0,-1) ) end

-- some other possible response. bounces pinball out of a bumper at a velocity of 100
system.callbacks["pinball"]["bumper"] = function(pb, bmpr) Bounce(pb, bmpr, 100) end

Also here's the extra functions I added to the hump vectors.

Code: Select all

-- returns quadrant of other from self. (1=topright, 2=topleft, 3=bottomleft, 4=bottomright)
function Vect:quadrant(other)
	return ( (other.x > self.x) and ((other.y < self.y) and 0 or 3 ) or 
                  ((other.y < self.y) and 1 or 2) ) + 1
end

-- returns the slope from self to other
function Vect:slope(other)
	return (self.y - other.y) / (self.x - other.x)
end

-- linear interpolate between self and other by amt
function Vect:lerp(other, amt)
	return self + (other - self):permul(Vect:new(amt, amt))
end

-- returns a vector with the absolute values of this one
function Vect:abs()
	return vector(abs(self.x), abs(self.y))
end

[Taehl]

It could be… they sure have the shakies and if dt gets too large they fall through.

fizz.update already has the line dt = math.min(dt, .2). But one of my planned improvements is to make sure that shapes (small ones especially) take multiple steps if they're moving very fast (or dt is large).

It will be horribly slow once you have a lot of objects, since you are testing every dynamic object against every other object.
Was "simple" to mean simple to use or as not having a lot code?

Not quite: Collisions between each pair are only checked once. So if you have, say, 10 dynamic shapes, there are only 45 checks instead of 90. Also, the check itself is decently efficient. Additionally, you could make a simple system to remove shapes that are out of the screen (assuming you have large levels with camera-scrolling), store them, and re-add them if they're in the screen again.
I thought "simple" meant "easy-to-use and simplistic (platformer-style) physics". But see, this is the sort of thing people should be discussing.

Using quadtrees and whatnot could help.

Definitely. I've never used them before, though, so I'd have to figure out how to make that work with variably-sized shapes (instead of just points).

[Taehl]

I just did a stress test. vrld, it ran at 60 FPS with over 100 dynamic objects. Doesn't seem so "horrible" to me.

I've updated that demo, if you'd like to see for yourself.

[kikito]

Using quadtrees and whatnot could help.

Definitely. I've never used them before, though, so I'd have to figure out how to make that work with variably-sized shapes (instead of just points).

I have some experience with improving quadtrees in Lua. Let me know if you need a hand.