HackManiac Posted April 27, 2013 Share Posted April 27, 2013 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 More sharing options...
rich Posted April 29, 2013 Share Posted April 29, 2013 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 More sharing options...
HackManiac Posted April 29, 2013 Author Share Posted April 29, 2013 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 More sharing options...
rich Posted April 29, 2013 Share Posted April 29, 2013 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 More sharing options...
HackManiac Posted April 29, 2013 Author Share Posted April 29, 2013 Wow, great news, looking forward to those additions! Thanks for all the effort, it's really appreciated! Link to comment Share on other sites More sharing options...
Recommended Posts