Simple, lightweight, general purpose collision detection

[tentus]

HardonCollider Update!

• Fixed polygon triangulation bug.
• Added Spatialhash:draw()
• Use class-commons for all the things

Usage of class commons is optional. If you don't use it, HC will work regardless. If you do, do it like so:

Code: Select all

class_commons = true
require 'slither'
Collider = require 'hardoncollider'
-- rest as usual

Awesome, dragged it into my current project and everything seems to be working great. Also, neat demo!

Edit: Just a note, you may want to increment your copyright for your next update.

[vrld]

Harder, Better, Faster, Stronger

In the last few months HardonCollider has undergone major (but mostly internal) changes:

• The new function HC:shapesAt(x,y) returns all shapes that contain the point (x,y) (brought to you by TechnoCat).
• HC:activeShapes() and shape:neighbors() are iterators to the active shapes and a shape's neighbors. In case you want to implement the detection loop yourself or do funky stuff in the collision callbacks.
• More importantly: speed improvements! The most significant speedup is gained by using a different (and much much faster) collision detection algorithm. The penetration vector should also be more accurate.
• Another speedup comes from using vector-light.lua (basically a table-less version of vector.lua). If you were using this module, you should use hump.vector from now on.

Besides the new functions and the removal of vector.lua the API did not change, so you should be able to just use the new code without any trouble.

However, if you experience bugs, please post them here or here. Same goes for feature requests.

[vrld]

Double Post! More updates!

1. Fixed a bug with polygon merging/convex decomposition.
2. Removed hash:getNeighbors() in favor of hash:inRange().
3. Added shape:scale that lets you change the size of a shape without removing and adding it.
4. Added HC:addShape(shape) that lets you add custom shapes if you are not satisfied with the available ones (see here). To be able to use the collision detection algorithm used by HC, you also need to implement shape:support(dx,dy). See here on how this works.
5. Added hash:inRange(), hash:rangeIter() and (more importantly) HC:shapesInRange(). This is stolen from inspired by bump.lua and mostly useful to quickly get the objects visible on the screen:

   Code: Select all

   for shape in pairs(HC:shapesInRange(camera:boundingBox()) do
       shape.parent:draw()
   end

[kikito]

awesome!

[ishkabible]

how does vecto-light.lua work?

edit:
never-mind; I looked at the source. have there been any issues using light vectors with other functions given that your just passing around groups of variables?

[bartbes]

have there been any issues using light vectors with other functions given that your just passing around groups of variables?

I assume he knew what he was doing, so he kept this in mind all the way through. I happen to know why he does this though, it's because all the table allocations for "full" vectors were a bottleneck, and simply using multiple return values increased performance quite a bit.
Now, as a word of advice, don't assume this is the case for your code, vrld found this after profiling his code.

[ishkabible]

I was actually aware of the reason for doing it. it's a bottle neck for most languages, allocation. and it *should* actually be more efficient in every case. because creation time, and access time are so much lower. there is no access time so check mate there; creation time is MUCH faster becuase allocation takes so long. depending on how copies are made(by reference or by value), the table could be slightly faster. with the table, you only need to copy 1 TValue*, with the doubles, you have to copy 2 TValue*(meaning two move instruction in the Lua VM, not just plain pointer moves) but this is drastically out weighed by the other benefits in most cases. if you copy the table by value then it becomes slower becuase a new table has to be allocated, and the elements have to accessed to be copied. but yes, profile your code first, always.

[bartbes]

and it *should* actually be more efficient in every case.

I wasn't saying it might not be more efficient, I was saying it might not be your bottleneck (and it probably isn't).

[ishkabible]

O, sorry; I misunderstood the use of bottleneck. yes, It probably wouldn't change performance very much unless your doing a lot of operations with vectors as in this case.

[vrld]

have there been any issues using light vectors with other functions given that your just passing around groups of variables?

The only thing you have to be careful with is how Lua handles multiple return variables. This will work:

Code: Select all

local x,y = vector.normalize(lx, ly)
local mag = vector.dot(x,y, vector.normalize(eye_x, eye_y)

while this wont:

Code: Select all

local mag = vector.dot(vector.normalize(lx, ly), vector.normalize(eye_x, eye_y)

It's also a pain - compared to "full" vectors - to write even just slightly complicated stuff. Case in point, the above could be written as:

Code: Select all

local mag = light:normalized() * eye:normalized()