Jump to content

Questions regarding GameObject.prototype.overlapsPoint


HackManiac
 Share

Recommended Posts

As I was trying to process mouse and touch event on a level selection screen I stumbled over the "overlaps..." family of functions provided by GameObject instances. I created a sprite for each level button but had some problems with using "overlapsPoint" function to detect whether the input event was inside of one of my sprites.

 

1. If I call "overlapsPoint" with a set of screen coordinates (and setting the second param to true), I get an "Uncaught TypeError: Cannot read property 'x' of undefined" because the "_point" variable of my Sprite instance is not initialized. I was able to circumvent that by initializing the "_point" variable in my constructor.

 

2. If I circumvent the problem in 1 (e.g. by passing a set of world coordinates), "overlapsPoint" does not respect rotation and alignment of the sprite.

 

I have now done the overlap check without the use of "overlapsPoint", but I wonder: did I use the function in a wrong way? Is there a Phaser-provided alternative to find a sprite at a given location? Whose responsibility is it to initialize the "_point" variable? Was it left uninitialized for a reason in the first place?

 

Any help is appreciated, thanks in advance!

 

Link to comment
Share on other sites

1) This is a bug and I'll fix it

 

2) It should work with alignment (as the bounds don't technically change) but definitely not rotation yet. All collision/intersection is done on straight AABB and I've not had a chance to implement OBB yet, sorry.

 

_point is a hangover from flixel I suspect. I'll make sure it is removed.

Link to comment
Share on other sites

Thanks for your reply, Rich.

 

 

 

2) It should work with alignment (as the bounds don't technically change) but definitely not rotation yet.

 

I thought "alignment" changed the meaning of "bounds.topLeft.x" and "bounds.topLeft.y"? I realized that during something similar to 

 

    http://jsfiddle.net/J3gdX/5/

 

If you replace "overlapsPointExt" with "overlapsPoint" on line 71 the button animation will only occur only if you hover over the lower right part of the button (and will occur far outside the sprite's visual borders) because that's the area defined by the "bounds" property. But "render" will blit the sprite to a modified position:

 

    https://github.com/photonstorm/phaser/blob/master/Phaser/gameobjects/Sprite.ts#L184

 

So although the values in the bounds property do not change, their meaning does. Or am I mistaken?

 

 

 

All collision/intersection is done on straight AABB and I've not had a chance to implement OBB yet, sorry.

 

No need to be sorry!

 

I hoped that "overlapsPoint" does not need an real OBB. My naive approach would have been (and partially already has been in a workaround after the jsfiddle patchwork) to transform the world / screen coordinate according to the scale and / or rotation and just AABB-check that resulting coordinate against the sprite's "bounds" property. To be honest I haven't done intensive testing on my substitute function, but I'll write some unit tests for it tomorrow to find out whether I was overly optimistic or oversaw something...

Link to comment
Share on other sites

Looking back over my notes I believe the issue at the moment is that align is literally just a rendering helper and doesn't update the bounds like it should. I've added it to the todo list for 0.9.5 as it's pretty important.

 

I really want collisions to work inclusive of rotation, across the board (input vs. object, object vs. object, etc) but it's quite a significant overhaul. At the moment the bounds doesn't adjust correctly when you rotate (enable renderDebug on a Sprite to see), i.e. it doesn't resize to allow for the size of the rotated sprite within it. If I used baked rotation that would be easier to drop in, but at a cost too!

 

I really want proper OBB across the board, but appreciate that Input needs a good kick-up the arse before 1.0. Your approach looks fine btw, the only spanner in the works is I've been adding Group level modifiers today, i.e. setting rotation/scale on a group and all children are influenced by that. Right now I don't use matrix transforms, if I did at least I could check out the parent and work through them that way, which is yet more work :) Lots to think about!

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...