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.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.
Fixed a bug with polygon merging/convex decomposition.
Removed hash:getNeighbors() in favor of hash:inRange().
Added shape:scale that lets you change the size of a shape without removing and adding it.
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.
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:
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?
ishkabible wrote:
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.
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.
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.