I've spent more time that what I wanted doing this, but I'm finally releasing this - another collision detection lib! It's called bump.lua
Note: This post is about an old version of bum. Post about bump.lua 2.0
The latest version can always be downloaded from github:
https://github.com/kikito/bump.lua
What does it do? Well, it does collision detection.
Comparison with HardonCollider
(TL;DR - if you are making a game with only bounding boxes, and you don't have incredibly fast objects, use bump. Otherwise, use HC)
So it is very similar to HardonCollider. But it does several things differently.
- Well, first and foremost, bump only handles axis-aligned boxes. No polygons, no circles, not even rotated boxes. If you wanted to use bump.lua with those, you would have to implement the collision part for those objects yourself (or just use HardonCollider).
- There is only one instance of bump at any given time. This means that you can't have several "worlds" occurring simultaneously, like you can in HC.
- bump doesn't take velocity into account when making calculations. This means that if you have very fast objects, they might "go through" others. In bump.lua, you have to pad your object's velocity.
- The interface is simpler. For example, since there are only boundingboxes, you just have a method for adding stuff (bump.add) and one for removing stuff (bump.remove).
- You don't need to use "bump objects" - you can use your own objects. The catch is that you have to tell bump how to get a bounding box for any object that you want to insert. By default bump will just try to call object:getBBox() to get the bounding box of the object (4 numbers - left, top, witdh, height). But you can change how the bounding box is calculated with the bump.getBBox callback.
- You don't need to tell bump when an object has changed positions - it tracks object movement automatically.
- The two main functions are called bump.collision(item1,item2,dx,dy) and bump.endCollision(item1, item2). Since there is only one instance of bump running at any given time, you can define them the same way you define LÖVE callbacks, without having to "pass them on to a constructor" (see the demo for an example).
- Groups/Categories/etc are handled via a callback, called bump.shouldCollide(item1, item2). If you make it return false, item1 and item2 will not generate collisions.
- You can use bump as a spatial hash - bump.each(f, l,t,w,h) will apply the function f to all the items in the box defined by l,t,w,h.
- The "update" function in bump is called bump.collide(). Called without parameters, it will calculate all collisions. But if you pass it a region with l,t,w,h, it will calculate collisions in that region only.
- There are some heuristics in how the order of the collisions executed. This should help when doing a platformer game, for example.
I'm attaching a platformer demo. It features a player character (move him with the arrows), a random blocky level, and 20 "gold coins" to pick up. The game is pretty much impossible if you just "jump around" to find the 20 gold coins. So I've included a "fly mode", which can be toggled on an off with the right shift key. Or you can try re-generating the level with the return key.
There is also a debug mode which will show you the underlying spatial grid, as well as the FPS/memory used (activate it with the TAB key).
My next step with this library is using it on battle-cry. Please try it out and let me know if you have any questions or comments.
EDIT: Attaching demo with v1.2. I'm leaving v1.0 attached for performance comparison