phaser/v3/merge/gameobjects/components/Events.js

296 lines
12 KiB
JavaScript
Raw Normal View History

2013-10-01 12:54:29 +00:00
/**
* @author Richard Davey <rich@photonstorm.com>
2016-04-04 21:15:01 +00:00
* @copyright 2016 Photon Storm Ltd.
2013-10-01 12:54:29 +00:00
* @license {@link https://github.com/photonstorm/phaser/blob/master/license.txt|MIT License}
*/
2013-09-08 21:38:19 +00:00
/**
* The Events component is a collection of events fired by the parent Game Object.
2016-05-04 01:02:13 +00:00
*
* Phaser uses what are known as 'Signals' for all event handling. All of the events in
* this class are signals you can subscribe to, much in the same way you'd "listen" for
* an event.
2013-11-28 15:57:09 +00:00
*
2016-05-04 01:02:13 +00:00
* For example to tell when a Sprite has been added to a new group, you can bind a function
* to the `onAddedToGroup` signal:
2013-11-28 15:57:09 +00:00
*
* `sprite.events.onAddedToGroup.add(yourFunction, this);`
2013-11-28 15:57:09 +00:00
*
* Where `yourFunction` is the function you want called when this event occurs.
2016-05-04 01:02:13 +00:00
*
* For more details about how signals work please see the Phaser.Signal class.
2013-11-28 15:57:09 +00:00
*
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
* The Input-related events will only be dispatched if the Sprite has had `inputEnabled` set to `true`
* and the Animation-related events only apply to game objects with animations like {@link Phaser.Sprite}.
2013-11-28 15:57:09 +00:00
*
* @class Phaser.Events
2013-10-01 12:54:29 +00:00
* @constructor
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
* @param {Phaser.Sprite} sprite - A reference to the game object / Sprite that owns this Events object.
2013-09-08 21:38:19 +00:00
*/
Phaser.Events = function (sprite) {
2014-03-23 07:59:28 +00:00
/**
* @property {Phaser.Sprite} parent - The Sprite that owns these events.
*/
this.parent = sprite;
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
// The signals are automatically added by the corresponding proxy properties
};
Phaser.Events.prototype = {
/**
* Removes all events.
*
* @method Phaser.Events#destroy
*/
destroy: function () {
this._parent = null;
if (this._onDestroy) { this._onDestroy.dispose(); }
if (this._onAddedToGroup) { this._onAddedToGroup.dispose(); }
if (this._onRemovedFromGroup) { this._onRemovedFromGroup.dispose(); }
if (this._onRemovedFromWorld) { this._onRemovedFromWorld.dispose(); }
if (this._onKilled) { this._onKilled.dispose(); }
if (this._onRevived) { this._onRevived.dispose(); }
if (this._onEnterBounds) { this._onEnterBounds.dispose(); }
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
if (this._onOutOfBounds) { this._onOutOfBounds.dispose(); }
if (this._onInputOver) { this._onInputOver.dispose(); }
if (this._onInputOut) { this._onInputOut.dispose(); }
if (this._onInputDown) { this._onInputDown.dispose(); }
if (this._onInputUp) { this._onInputUp.dispose(); }
if (this._onDragStart) { this._onDragStart.dispose(); }
if (this._onDragUpdate) { this._onDragUpdate.dispose(); }
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
if (this._onDragStop) { this._onDragStop.dispose(); }
if (this._onAnimationStart) { this._onAnimationStart.dispose(); }
if (this._onAnimationComplete) { this._onAnimationComplete.dispose(); }
if (this._onAnimationLoop) { this._onAnimationLoop.dispose(); }
},
// The following properties are sentinels that will be replaced with getters
/**
* This signal is dispatched when this Game Object is added to a new Group.
* It is sent two arguments:
* {any} The Game Object that was added to the Group.
* {Phaser.Group} The Group it was added to.
* @property {Phaser.Signal} onAddedToGroup
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onAddedToGroup: null,
/**
* This signal is dispatched when the Game Object is removed from a Group.
* It is sent two arguments:
* {any} The Game Object that was removed from the Group.
* {Phaser.Group} The Group it was removed from.
* @property {Phaser.Signal} onRemovedFromGroup
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onRemovedFromGroup: null,
/**
* This Signal is never used internally by Phaser and is now deprecated.
* @deprecated
* @property {Phaser.Signal} onRemovedFromWorld
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onRemovedFromWorld: null,
/**
* This signal is dispatched when the Game Object is destroyed.
* This happens when `Sprite.destroy()` is called, or `Group.destroy()` with `destroyChildren` set to true.
* It is sent one argument:
* {any} The Game Object that was destroyed.
* @property {Phaser.Signal} onDestroy
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onDestroy: null,
/**
* This signal is dispatched when the Game Object is killed.
* This happens when `Sprite.kill()` is called.
* Please understand the difference between `kill` and `destroy` by looking at their respective methods.
* It is sent one argument:
* {any} The Game Object that was killed.
* @property {Phaser.Signal} onKilled
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onKilled: null,
/**
* This signal is dispatched when the Game Object is revived from a previously killed state.
* This happens when `Sprite.revive()` is called.
* It is sent one argument:
* {any} The Game Object that was revived.
* @property {Phaser.Signal} onRevived
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onRevived: null,
/**
* This signal is dispatched when the Game Object leaves the Phaser.World bounds.
* This signal is only if `Sprite.checkWorldBounds` is set to `true`.
* It is sent one argument:
* {any} The Game Object that left the World bounds.
* @property {Phaser.Signal} onOutOfBounds
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onOutOfBounds: null,
/**
* This signal is dispatched when the Game Object returns within the Phaser.World bounds, having previously been outside of them.
* This signal is only if `Sprite.checkWorldBounds` is set to `true`.
* It is sent one argument:
* {any} The Game Object that entered the World bounds.
* @property {Phaser.Signal} onEnterBounds
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onEnterBounds: null,
2013-09-08 21:38:19 +00:00
/**
* This signal is dispatched if the Game Object has `inputEnabled` set to `true`,
* and receives an over event from a Phaser.Pointer.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* @property {Phaser.Signal} onInputOver
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onInputOver: null,
/**
* This signal is dispatched if the Game Object has `inputEnabled` set to `true`,
* and receives an out event from a Phaser.Pointer, which was previously over it.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* @property {Phaser.Signal} onInputOut
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onInputOut: null,
/**
* This signal is dispatched if the Game Object has `inputEnabled` set to `true`,
* and receives a down event from a Phaser.Pointer. This effectively means the Pointer has been
* pressed down (but not yet released) on the Game Object.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* @property {Phaser.Signal} onInputDown
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onInputDown: null,
/**
* This signal is dispatched if the Game Object has `inputEnabled` set to `true`,
* and receives an up event from a Phaser.Pointer. This effectively means the Pointer had been
* pressed down, and was then released on the Game Object.
* It is sent three arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* {boolean} isOver - Is the Pointer still over the Game Object?
* @property {Phaser.Signal} onInputUp
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onInputUp: null,
/**
* This signal is dispatched if the Game Object has been `inputEnabled` and `enableDrag` has been set.
* It is sent when a Phaser.Pointer starts to drag the Game Object, taking into consideration the various
* drag limitations that may be set.
* It is sent four arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* {number} The x coordinate that the drag started from.
* {number} The y coordinate that the drag started from.
* @property {Phaser.Signal} onDragStart
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onDragStart: null,
/**
* This signal is dispatched if the Game Object has been `inputEnabled` and `enableDrag` has been set.
* It is sent when a Phaser.Pointer is actively dragging the Game Object.
* Be warned: This is a high volume Signal. Be careful what you bind to it.
* It is sent six arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* {number} The new x coordinate of the Game Object.
* {number} The new y coordinate of the Game Object.
* {Phaser.Point} A Point object that contains the point the Game Object was snapped to, if `snapOnDrag` has been enabled.
* {boolean} The `fromStart` boolean, indicates if this is the first update immediately after the drag has started.
* @property {Phaser.Signal} onDragUpdate
*/
onDragUpdate: null,
/**
* This signal is dispatched if the Game Object has been `inputEnabled` and `enableDrag` has been set.
* It is sent when a Phaser.Pointer stops dragging the Game Object.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Pointer} The Phaser.Pointer object that caused the event.
* @property {Phaser.Signal} onDragStop
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onDragStop: null,
2013-09-08 21:38:19 +00:00
/**
* This signal is dispatched if the Game Object has the AnimationManager component,
* and an Animation has been played.
* You can also listen to `Animation.onStart` rather than via the Game Objects events.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Animation} The Phaser.Animation that was started.
* @property {Phaser.Signal} onAnimationStart
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onAnimationStart: null,
/**
* This signal is dispatched if the Game Object has the AnimationManager component,
* and an Animation has been stopped (via `animation.stop()` and the `dispatchComplete` argument has been set.
* You can also listen to `Animation.onComplete` rather than via the Game Objects events.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Animation} The Phaser.Animation that was stopped.
* @property {Phaser.Signal} onAnimationComplete
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onAnimationComplete: null,
/**
* This signal is dispatched if the Game Object has the AnimationManager component,
* and an Animation has looped playback.
* You can also listen to `Animation.onLoop` rather than via the Game Objects events.
* It is sent two arguments:
* {any} The Game Object that received the event.
* {Phaser.Animation} The Phaser.Animation that looped.
* @property {Phaser.Signal} onAnimationLoop
*/
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
onAnimationLoop: null
2013-10-13 00:29:57 +00:00
};
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
Phaser.Events.prototype.constructor = Phaser.Events;
2013-10-13 00:29:57 +00:00
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
// Create an auto-create proxy getter and dispatch method for all events.
// The backing property is the same as the event name, prefixed with '_'
// and the dispatch method is the same as the event name postfixed with '$dispatch'.
for (var prop in Phaser.Events.prototype)
{
if (!Phaser.Events.prototype.hasOwnProperty(prop) ||
prop.indexOf('on') !== 0 ||
Phaser.Events.prototype[prop] !== null)
{
continue;
}
2013-10-13 00:29:57 +00:00
(function (prop, backing) {
'use strict';
// The accessor creates a new Signal; and so it should only be used from user-code.
Object.defineProperty(Phaser.Events.prototype, prop, {
get: function () {
return this[backing] || (this[backing] = new Phaser.Signal());
}
});
// The dispatcher will only broadcast on an already-created signal; call this internally.
Phaser.Events.prototype[prop + '$dispatch'] = function () {
return this[backing] ? this[backing].dispatch.apply(this[backing], arguments) : null;
};
})(prop, '_' + prop);
Event-Signal object count optimization 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.
2014-12-01 03:49:15 +00:00
}