Tilemap.getRayCastTiles now requires a Phaser.TilemapLayer (or Phaser.TilemapLayerGL) as the first argument.
Tilemap.getTiles now requires a Phaser.TilemapLayer (or Phaser.TilemapLayerGL) as the first argument.
Clean up _initWebGL to remove unused GL buffers.
Clean up _renderBatch to remove unused srcWide/srcHigh variables.
Set new Tile Shader's clipping uniform using displayWidth/Height.
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
transformations;
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
ignore them.
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.
* Documentation
* 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:
1.
http://www.nedyalkov.net/filip/demos/phaser/IncorrectDisplayObjectDimensionsDemo_v2.5.0/
2.
http://www.nedyalkov.net/filip/demos/phaser/IncorrectDisplayObjectDimensionsDemo_v2.6.1/
3.
http://www.nedyalkov.net/filip/demos/phaser/IncorrectDisplayObjectDimensionsDemoFixed_v2.6.1/
Here is a zip file of the demo projects (build with VS2015):
http://www.nedyalkov.net/filip/demos/phaser/IncorrectDisplayObjectDimensionsDemos.zip
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!
Thank you!
Group.getAll will return all children in the Group, or a section of the Group, with the optional ability to test if the child has a property matching the given value or not.
Group.iterate has a new `returnType`: `RETURN_ALL`. This allows you to return all children that pass the iteration test in an array.
Groups have a new method `alignIn`. It allows you to align the Group within another Game Object, or a Rectangle. You can specify one of 9 positions which are the new position constants such as: `Phaser.TOP_LEFT` or `Phaser.CENTER` (see docs for the complete list). The Groups are positioned based on their child bounds, which takes rotation and scaling into consideration. You can easily place Groups into the corners of the screen, or game world, or align them within other Sprites, using this method.
Groups have a new method `alignTo`. It allows you to align a Group to the side of another Game Object, or a Rectangle. You can specify one of 11 positions which are the new position constants such as: `Phaser.TOP_LEFT` or `Phaser.LEFT_BOTTOM` (see docs for the complete list). The Groups are positioned based on their child bounds, which takes rotation and scaling into consideration. You can easily align Groups next to other Sprites using this method.
ArcadePhysics.Body.onOverlap is a new Signal that is dispatched whenever the Body overlaps with another Body. Due to the potentially high volume of signals this could create it is disabled by default. To use this feature set this property to a Phaser.Signal: `sprite.body.onOverlap = new Phaser.Signal()` and it will be called when an overlap happens, passing two arguments: the sprites which collided.
ArcadePhysics.World.separateCircle is a new method that handles all circular body collisions internally within Arcade Physics (thanks @VitaZheltyakov)
All of the Arcade Physics internal methods, such as `collideGroupVsSelf`, `collideSpriteVsSprite` and so on, have been updated to work with circular body shapes (thanks @VitaZheltyakov)
ArcadePhysics.Body.onWorldBounds is a new Signal that is dispatched whenever the Body collides with the world bounds, something that was previously difficult to detect. Due to the potentially high volume of signals this could create it is disabled by default. To use this feature set this property to a Phaser.Signal: `sprite.body.onWorldBounds = new Phaser.Signal()` and it will be called when a collision happens, passing one argument: the sprite on which it occurred.
* The PIXI.BaseTexture.imageUrl property has been removed, as it was never actually populated.
* The PIXI.BaseTexture._UID property has been removed, as it was never actually used internally.
* All references to PIXI.BaseTextureCache have been removed (primarily from BaseTexture.destroy and Texture.destroy), as the BaseTextureCache was never used internally by Phaser, or by our custom version of Pixi.
* PIXI.TextureCache has been removed. It was only ever used by the __default and __missing images that Phaser generates on start-up. It wasn't used internally by Phaser anywhere else, and the only references Pixi has to it have all been removed. If you need it in your own game, please refactor it to avoid it, or re-create the object on the PIXI global object.
* Canvases created by `BaseTexture.fromCanvas` no longer have the `_pixiId` property attached to them, as this was never used internally by Phaser or Pixi.
* PIXI.BaseTexture.updateSourceImage is now deprecated. Please use `Sprite.loadTexture` instead.
* The property PIXI.BaseTextureCacheIdGenerator has been removed, as it is no longer used internally by Phaser or Pixi.
* PIXI.Texture.addTextureToCache has been removed. The PIXI Texture Cache was never actually used by Phaser, and was leading to complications internally.
* PIXI.Texture.removeTextureFromCache has been removed. The PIXI Texture Cache was never actually used by Phaser, and was leading to complications internally.
* PIXI.Texture.fromFrame and PIXI.Sprite.fromFrame have been removed. They relied on the PIXI Texture Cache, which was never actually used by Phaser, and was never used internally by Pixi either.
* The property PIXI.TextureCacheIdGenerator has been removed, as it was not used internally.
* The property PIXI.FrameCache has been removed, as it was not used internally.
* The missing image texture, for when an image has failed to load, is now available under `Phaser.Cache.MISSING`.
* Phaser.Cache.addImage will now check the key given, and if `__default` or `__missing` it will update the new consts `Phaser.Cache.DEFAULT` and `Phaser.Cache.MISSING` accordingly, allowing you to replace the default or missing image textures used by Phaser.
* Phaser.Cache.getPixiTexture has now been removed, as the Pixi Cache isn't used internally anywhere any longer.
* Phaser.Cache.getPixiBaseTexture has now been removed, as the Pixi Cache isn't used internally anywhere any longer.
Graphics objects enabled for input would fail to do anything if a Phaser Polygon was given to the Graphics object (which it was in nearly all cases), as it wouldn't detect input correctly with flattened polygons (thanks @symbiane #2591)
PIXI.Tilemap - _renderBatch using a local 'degenerate' flag to signal to next iteration that one should be inserted before the next triangle.
Phaser.TilemapLayerGL - add degenerate markers at end of rows and whenever a row has a break in it (e.g. empty tiles)
Phaser.Tileset - new addDegenerate function which prevents double markers in a row
Phaser.Tilemap now creates internal map layers for each tileset except the first one (which will be handled by the createLayer call from the game). It also stores a reference to each tileset where the new map layers can access it.
Phaser.TilemapLayerGL uses the new tileset reference to ensure the correct base image and tile sizes are used for each new layer.
PIXI.Tilemap: added initialisation of glBatch to null in c'tor.
Phaser.TilemapParser was cleaned up to remove the now unnecessary tilemap parameter and the attempt to create layers while parsing.
BitmapData.copyTransform allows you to draw a Game Object to the BitmapData, using its `worldTransform` property to control the location, scaling and rotation of the object. You can optionally provide
BitmapData.drawGroup now uses the new `copyTransform` method, to provide for far more accurate results. Previously nested Game Objects wouldn't render correctly, nor would Sprites added via `addChild` to another Sprite. BitmapText objects also rendered without rotation taken into account, and the Sprites smoothing property was ignored. All of these things are now covered by the new drawGroup method, which also handles full deep iteration down the display list.
The `DisplayObject.worldScale` value didn't multiply the local objects scale into the calculation, meaning the value wasn't a true representation of the objects world scale.
Group.onChildInputUp is a new Signal that you can listen to. It will be dispatched whenever any immediate child of the Group emits an `onInputUp` signal itself. This allows you to listen for a Signal from the Group, rather than every Sprite within it.
Group.onChildInputOver is a new Signal that you can listen to. It will be dispatched whenever any immediate child of the Group emits an `onInputOver` signal itself. This allows you to listen for a Signal from the Group, rather than every Sprite within it.
Group.onChildInputOut is a new Signal that you can listen to. It will be dispatched whenever any immediate child of the Group emits an `onInputOut` signal itself. This allows you to listen for a Signal from the Group, rather than every Sprite within it.
Group.addAt has been refactored to be a simple call to `Group.add`, removing lots of duplicate code in the process.
Group.create has a new optional argument `index` which controls the index within the group to insert the child to. Where 0 is the bottom of the Group. It also now makes proper use of `Group.add`, cutting down on more duplicate code.
Group.createMultiple now returns an Array containing references to all of the children that the method created.
The purpose of `processInteractiveObjects` is to work out which Game Object the Pointer is going to
interact with. It works by polling all of the valid game objects, and then slowly discounting those
that don't meet the criteria (i.e. they aren't under the Pointer, are disabled, invisible, etc).
Eventually a short-list of 'candidates' is created. These are all of the Game Objects which are valid
for input and overlap with the Pointer. If you need fine-grained control over which of the items is
selected then you can use this callback to do so.
The callback will be sent 3 parameters:
1) A reference to the Phaser.Pointer object that is processing the Items.
2) An array containing all potential interactive candidates. This is an array of `InputHandler` objects, not Sprites.
3) The current 'favorite' candidate, based on its priorityID and position in the display list.
Your callback MUST return one of the candidates sent to it.
Pointer.swapTarget allows you to change the `Pointer.targetObject` object to be the one provided. This allows you to have fine-grained control over which object the Pointer is targeting.
InputHandler._pointerOverHandler and _pointerOutHandler have new arguments `silent` - if `true` then they will not dispatch any Signals from the parent Sprite.
Number.MIN_VALUE does not return the most negative number, but rather the smallest representable number above 0. As a result, Phaser.Rectangle.aabb() did not work correctly when the points had negative values.
InputHandler.dragTimeThreshold gives you more fine control over when a Sprite Drag event will start. It allows you to specify a time, in ms that the pointer must have been held down for, before the drag will begin.
InputHandler.downPoint is a new Point object that contains the coordinates of the Pointer when it was first pressed down on the Sprite.
