Am I missing a trick? Extending checkCollisions beyond axis-aligned bounding boxes

SDK Get Help
1

The thing I’m working on involves wadding a bunch or early eras of gaming into a ball and making them play well together. Up to this point, everything’s been axis-aligned bounding boxes and I’ve enjoyed the simplicity, accuracy, and performance of the SDK’s stock checkCollisions() system. But I need to add circle colliders for some stuff (heck, even Spacewar had octagonal colliders in 1962!) and I can’t trust myself not to add bitmap collisions and even unaligned bounding boxes for some really dumb reasons.

So it would seem it’s my turn to implement my own collision detection more or less from scratch, and the most I can retain from the SDK is sprite:overlappingSprites(), which buys me collision groups and a coarse detection pass using the old collision rects. Which I’ll take! Those are very nice to have!

This bothers me, though, because nearly everything in my world is still going to be axis-aligned bounding boxes anyway, and I’ll end up with a worse-performing implementation of restitution for those. There are these hints littered in the docs for sprite:collisionResponse() and sprite:alphaCollision() (not to mention bump.lua’s addResponse() for custom collision callbacks) that suggest that the existing bounding box restitution system was meant to be a bit extensible. But when I game out doing something like running checkCollisions and re-resolving all the non-AABB collisions encountered in a step, things get really gross. Smuggling side effects into sprite:collisionResponse() seems like the only way you could really get away without redoing the whole collision pass from scratch every time a non-box object got approached, but you don’t have access to enough information inside of the pending collision to make meaningful determinations there.

Is anyone actually extending moveWithCollisions() or checkCollisions() to correct fine-grained collision behavior, or am I just consigned to redoing the same old collision code from scratch but for my purposes like everybody else who gets to this point?

2

Hey! Apologies in advance for the not-extremely-helpful reply.

Improved collisions is definitely something of interest for many types of games - I believe a lot of people go about it either by re-coding themselves, or they use an external library like Box2D (although this is a C-implementation).

I eventually got some help from another developer while working on Wheel Runner (where the main character should have Circle collisions, no surprise there :stuck_out_tongue: ), and they put together a re-implementation of both circle and rectangular collisions in lua. You can take a look at part of it here: playjam-2022/source/engine/collisionSolver.lua at wheel-mvt · Franchovy/playjam-2022 · GitHub

Unfortunately I never got around to merging it since on top of all the additional stuff I was doing, the framerate ran pretty slowly. (I don't think it's necessarily the collisions causing it, since without them the framerate was below 30 as well). However, if you do decide to make some progress in this direction and make it available to the public, I think that would be an amazing thing and I would love to be of some help!

3

Thanks. Looks like this is another whole-cloth solution. That’s evidently the easy and obviously correct approach; trouble is I’m attacking this whole thing from a recreational coding angle where “easy and obviously correct” isn’t nearly as valued as “aesthetically pleasing to me”. So I’ll do something dumb that only makes sense to me, and if it actually is accidentally good and efficient, I’ll definitely share it out. Just wanted to make sure that I wasn’t missing a correct answer that actually appealed to my dumb and arbitrary sensibilities.