Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
hitTestPoint() behavior — Gideros Forum

hitTestPoint() behavior

hgy29hgy29 Maintainer
edited July 2015 in Roadmap
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()..


  • ar2rsawseenar2rsawseen Maintainer
    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 :)
  • hgy29hgy29 Maintainer
    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) ?
  • 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.
  • piepie Member
    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! ^:)^
  • ar2rsawseenar2rsawseen Maintainer
    Accepted Answer
    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

    Likes: pie, keszegh, hgy29

    +1 -1 (+3 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    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)...
  • XmanXman Member
    why not just leave the visibility check to users?
    Take clip into account is very good.
  • 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.
  • totebototebo Member
    +1 for the hitTestPoint(x,y,true) solution.
    My Gideros games: www.totebo.com
  • SinisterSoftSinisterSoft Maintainer
    +1 for hitTestPoint(x,y,clip/invis,transparent,mask) ;)
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
Sign In or Register to comment.