Speed penalty for using love.physics over a simpler Lua lib?

[benhumphreys]

I'm doing platformer collision stuff again, and I'm torn between using love.physics and HardonCollider.

My main worry is from the warning on the Wiki that says

love.physics is not lightweight, and not even remotely simple to use. It's a ten-ton hammer designed for heavy-lifting (er...hammer...lifting?)
If you are just trying to make a character jump around on blocks or the likes, then move along, nothing to see here.

Is there a speed penalty associated with using love.physics over something like HardonCollider? Isn't it C/C++ under the hood, whereas HC is pure Lua?

I'm unlikely to use the more advanced features of love.physics so you could say it's overkill, but its collision detection seems a lot better than HardonCollider that has given me problems in the past.

[Inny]

The short answer is that if you have a very small set of objects that will be colliding (like the player and a pair or three of enemies), then no, the performance differences are negligible. Even a poorly written collision library that just does an AABB collision checks between objects without any kind of broadphase filtering, as long as the set of objects is very small, then no hard work is really being done at all. Why love.physics might be a bad idea for a small game with a simple set of objects, is that the programming overhead of setting up, using, and understanding love.physics is kind of large. Unless you're actively seeking to learn everything there is to learn about love, your time is better spent actually making the game, rather than farting around in library code.

[Robin]

tl;dr: there is a speed penalty for using love.physics, but that's in your brain, not in your game.

[benhumphreys]

Why love.physics might be a bad idea for a small game with a simple set of objects, is that the programming overhead of setting up, using, and understanding love.physics is kind of large. Unless you're actively seeking to learn everything there is to learn about love, your time is better spent actually making the game, rather than farting around in library code.

Good point! Thanks. At this point I've spent enough time with Löve that I think I've already done the overhead of learning and setting up love.physics.

I have one follow-up question, again about efficiency.
Most of the time I want to do physical collisions, that stop the elements from moving.
But I also want to know when non-colliding things overlap, for instance when a player is standing in front of a door.

As far as I know, the only way to do this with love.physics is the following snippet:

Code: Select all

function preSolve(a, b, coll)
  if a:getUserData() == "non collision thing" or b:getUserData() == "non collision thing" then
    coll:setEnabled(false)
  end
end

Is this the best way? It seems kind of inefficient to have to check every preSolve collision.

Also am I right in thinking I have to check both a and b because I don't know what order they're being passed in?