hitTestPoint() behavior

hgy29

Hi guys,

I guess most of us use Sprite:hitTestPoint() for testing wether some mouse/touch event is inside the rectangular area of a given sprite. Now that you can clip() a sprite, I was wondering if hitTestPoint should also take clipping and visibility into account, i.e. return false when the coordinates are clipped-out or if the sprite was "setVisible(false)".

What do you think ? Do some of you use hitTestPoint for some other matter that would be broken up by such changes ?
Obviously setClip is quite recent so I don't believe it would harm to check for it, but I am not so sure about setVisible()..

ar2rsawseen

clipping sure, but you can most probably take clipping bounds instead of real bounds, same as width maybe needs to return clip bounds instead of real bounds?

real problem will be when we will have masking, then you will need to check alpha value too

hgy29

Well I don't think getWidth()/getHeight() should honor clipping, because it is still useful to query the unclipped size... Masking will surely bring a full new set of issues :P
But what about sprite visibility ? Should a sprite that has been made hidden through Sprite:setVisible(false) responds systematically false to hitTestPoint, or current behavior is the good one (visibility ignored) ?

keszegh

for visibility current is better as it's easy to workaround it in case you want the behaviour you propose.
while the other direction won't be possible.

pie

I worked around that using ar2rsawseen's Sprite:hide()/show().
I suppose it could be useful to keep it this way (visibility ignored) to have a chance of using "invisible buttons", but maybe that could be achieved either setting their alpha to 0.

I agree hitTestPoint should take into account setClip bounds though, and maybe it could be useful to allow query on both sizes: "clipped" and "original", not that I know I will need it... but who knows?

thank you for your work! ^:)^

ar2rsawseen

how about making hitTestPoint(x,y,true) providing last value true to ignore transparent areas, which would take clipping and masking into consideration

So all current implementations would work as is and does not break backwards compatibility

hgy29

For now I'll add a single boolean value to hitTestPoint to indicate that clipping and visibility must be checked (if true), but I am thinking about something more complete in the future.

The main idea is to provide a way to ignore transparent parts of a sprite, but doing so may become CPU and/or GPU intensive. Perhaps we could allow to pass a bounding shape to hitTestPoint(), to further reduce the active area of a Sprite. Or perform a texture lookup to check for transparent areas (for bitmaps only)...

Xman

why not just leave the visibility check to users?
Take clip into account is very good.

tkhnoman

I think it is also better to just leave it to the user for transparent areas of texture.
I myself always use more area than just the visible part, so i can make sure it can be touched even if they did not precisely touching it.

totebo

+1 for the hitTestPoint(x,y,true) solution.

SinisterSoft

+1 for hitTestPoint(x,y,clip/invis,transparent,mask)