get/isTouching is slow

[tjvr]

Maybe we can think about changing the default? Do something smart with minimal bounding boxes perhaps?

[bates64]

Perhaps model after the functions that Gamemaker's GML api provides as well as an isTouching function? It has optimised functions for different shapes.

I'd love a sprite.placeMeeting(x, y) function. Hell, isTouching could support (x, y) and (otherSprite) as one function...

[bates64]

On defaults, I'd say rename the current isTouching to something like isTouchingPerfect, and make an AABB version for isTouching to be. We must mention this in the docs though, since the behaviour is different to Scratch.

[tjvr]

the functions that Gamemaker's GML api provides

Hmm, I'm not sure about those. I find place_meeting particularly confusing: the naming isn't clear, and it's something you can easily implement yourself: indeed, I'd argue that implementing it yourself (setting the position, checking for a collision, moving it back) is less confusing.

---

I suppose we could allow setting the "shape" or "bounds" of an object: you might want to be able to treat an emoji as a circle for the purposes of collisions, for example. (🏀 anyone?)

If we were going to go down that route, I suppose it might make sense to offer polygon/polygon collisions etc. But that's a particularly nasty problem to solve, and it's unclear whether it would be very helpful.

Plain rect/rect collisions gets you surprisingly far.

[tjvr]

@ISNIT0 Joe, what do you think about this? :-)