getObjectUnderPoint doesn't work on container

[danielribeiro]

On version 0.2 worked great. A simple way to show this is to put the bitmap on the drag and drop example on a container. No configuration of mouseenabled/mouseChildren made this work.

[gskinner]

In the new interaction model, containers are not returned for getObjectUnderPoint, however you can use "contains" to check if the item returned is within the container. You should also be able to use Container.hitTest to check if a container is under a point, however this is currently broken - I will fix this in an update very soon.

This report also led me to find a major issue with triggering onPress/Click handlers on containers, which is now resolved.

Given the above, would you still want to be able to get containers returned in getObjectUnderPoint? If so, what would you expect the property to be named for making a container return instead it's children? "mouseChildren" was misleading, because it didn't really involve the mouse. "treatContainerAsGroupForObjectsUnderPoint" is a little verbose.

[danielribeiro]

Well, as I told on this tweet, I am moving away from getObjectUnderPoint. I need actual collision detection algorithms, so alpha checking no longer solves my point, When this is done, I'll try again coming back to 0.3.

But thanks for the reply.

[gskinner]

To address the original point, I just pushed an update that fixes hitTest and mouse event callbacks for containers.

For collision detection, are you looking for SAT collisions? I think it would be pretty straightforward to implement this as a layer on top of EaselJS, but is unlikely to be part of the core library. I'd like to keep the core of EaselJS focused on being a strong display management library, which people can easily extend for more specific purposes.

Here's a starting point, from the developer of crafty.js: http://craftyjs.tumblr.com/post/3096403769/sat-collision-made-easy-part-1

[danielribeiro]

I wish to implement SAT. However, I'll keep it simple for now. The naive approach is easy enough to implement and test (was already implemented), and will suffice. If things get too slow, quadtrees shall probably be enough.

I don't want to get too caught up to this, as I may have to switch to Box2DJS, which use SAT.

But I agree with your approach. Collision detection on the core library can be too much too soon.

I am just glad I'll not have to implement general Computational Geometry techniques (in particular these ones) for collision detection.

Thanks for the links.

[gskinner]

Closing.

[danielribeiro]

Ok, the issue is fixxed. The dicussion that lingered (was a good one btw).