…bounds do NOT retrieve proper values
* TypeScript Defs
* Nothing, it's a bug fix
Describe the changes below:
I noticed that getting dimensions or bounds changed in Phaser 2.6.1 and
it was bugged - returned dimensions were doubled in the direction of the
scaling for example, but the nice thing was that this time the
dimensions included the rotation of the object - which I think should be
the default behavior. It also bugged getLocalBounds which started
returning global getBounds();
When I checked the previous version of phaser 2.5.0 - total different
story. getLocalBounds returns the object without any transformations to
it. Getting width and height works ok, but rotation wasn't calculated to
the dimensions at all.
In all cases only getBounds returned proper dimensions, which is
obviously not enough and this is also a very important issue to be
resolved as soon as possible since it's a major core component feature
used all the time.
That's why I decided to spare the time and hopefully find a good fix for
all of this mess and I think I finally got there and tried to make the
changes as much as possible with your Code of Conduct. This is actually
the first time I am requesting a pull so I hope it will do some good. I
did compare my results with how Flash handles dimensions - they match,
so I do hope I didn't miss something and believe you guys would make
sure everything works ok.
To help you with reviewing and possibly (and hopefully) accepting this
pull request I've made available online 3 demos of the issues and with
demo of the fix of course:
Here is a zip file of the demo projects (build with VS2015):
I really hope to see this FIX in the next version - would help me and a
lot of people I guess to get the job done properly!
… dimensions and bounds
With the previous fix what the getBounds did was:
1) if targetCoordinateSpace is the same instance as the caller of
getBounds(), then it will return the bounds of the caller without any
2) if targetCoordinateSpace is null/undefined it will return the global
bounds of the caller.
3) if targetCoordinateSpace is any valid DisplayObject it will return
the local bounds of the caller.
What this fix does is fixing 3) along with other obsolete code that
wasn't necessary so I reverted it.
So now if the targetCoordinateSpace is a valid DisplayObject:
- if it's a parent of the caller at some level it will return the bounds
relative to it
- if it's not parenting the caller at all it will get global bounds of
it and the caller and will calculate the x and y bounds of the caller
relative to the targetCoordinateSpace DisplayObject
Also I have fixed how empty groups are treated when they have no other
children except groups, so now calculations are correct. They obviously
have 0 width and height but are still being positioned and other things
could possibly relate to that bounds and it didn't make sense to me to
Also added a DisplayObjectContainer.contains(child) method which
determines whether the specified display object is a child of the
DisplayObjectContainer instance or the instance itself. This method is
used in the new getBounds function.
Corrected DisplayObject's default _bounds rect from (0, 0, 1, 1), to (0,
0, 0, 0) - it doesn't seem to break anything and also in the getBounds
before the fix, when there were no children it assigned a (0, 0, 0, 0)
rectangle to it so I am pretty sure it's safe to correct it.