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.
Group.getFirstDead, Group.getFirstAlive and Group.getFirstExists all have new optional arguments: `createIfNull`, `x`, `y`, `key` and `frame`. If the method you call cannot find a matching child (i.e. getFirstDead cannot find any dead children) then the optional `createIfNull` allows you to instantly create a new child in the group using the position and texture arguments to do so. This allows you to always get a child back from the Group and remove the need to do null checks and Group inserts from your game code. The same arguments can also be used in a different way: if `createIfNull` is false AND you provide the extra arguments AND a child is found then it will be passed to the new `Group.resetChild` method. This allows you to retrieve a child from the Group and have it reset and instantly ready for use in your game without any extra code.
Group.physicsSortDirection is a new property allowing you to set a custom sort direction for Arcade Physics Sprites within the Group hash. Previously Arcade Physics used one single sort direction (defined on `Phaser.Physics.Arcade.sortDirection`) but this change allows you to specifically control how each and every Group is sorted, so you can now combine tall and wide Groups with narrow and thin in a single system.
As pointed out, `newChild.parent` could be accessed after it was set to
undefined. This fix unifies the code from the various `destroy` methods so
the previou issue does not occur.
There are a bunch of signals added for Sprites; more when input is
enabled. However, very few of these signals are ever actually used. While
the previous performance update related to Signals addressed the size of
each Signal object, this update is to reduce the number of Signal objects
as used by the Events type.
As a comparison the "Particle: Random Sprite" demo creates 3200+ Signals;
with this change there less than 70 signals created when running the same
demo. (Each Event creates at 8 signals by default, and there is an Event
for each of the 400 particles.) While this is an idealized scenario, a
huge amount (of albeit small) object reduction should be expected.
It does this by creating a signal proxy property getter and a signal
dispatch proxy. When the event property (eg. `onEvent`) is accessed a new
Signal object is created (and cached in `_onEvent`) as required. This
ensures that no user code has to perform an existance-check on the event
property first: it just continues to use the signal property as normal.
When the Phaser game code needs to dispatch the event it uses
`event.onEvent$dispath(..)` instead of `event.onEvent.dispatch(..)`. This
special auto-generated method automatically takes care of checking for if
the Signal has been created and only dispatches the event if this is the
case. (If the game code used the `onEvent` property itself the event
deferal approach would be defeated.)
This approach is designed to require minimal changes, not negatively
affect performance, and reduce the number of Signal objects and
corresponding Signal/Event resource usage.
The only known user-code change is that code can add to signal (eg.
onInput) events even when input is not enabled - this will allow some
previously invalid code run without throwing an exception.
