phaser/src/gameobjects/Events.js

187 lines
6.6 KiB
JavaScript
Raw Normal View History

2013-10-01 12:54:29 +00:00
/**
* @author Richard Davey <rich@photonstorm.com>
2014-02-05 05:54:25 +00:00
* @copyright 2014 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.
2013-11-28 15:57:09 +00:00
*
* For example to tell when a Sprite has been added to a new group:
*
* `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.
*
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._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._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
/**
* @property {Phaser.Signal} onAddedToGroup - This signal is dispatched when the parent is added to a new Group.
*/
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,
/**
* @property {Phaser.Signal} onRemovedFromGroup - This signal is dispatched when the parent is removed from a Group.
*/
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,
/**
* @property {Phaser.Signal} onRemovedFromWorld - This signal is dispatched if this item or any of its parents are removed from the game world.
*/
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,
/**
* @property {Phaser.Signal} onDestroy - This signal is dispatched when the parent is destoyed.
*/
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,
/**
* @property {Phaser.Signal} onKilled - This signal is dispatched when the parent is killed.
*/
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,
/**
* @property {Phaser.Signal} onRevived - This signal is dispatched when the parent is revived.
*/
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,
/**
* @property {Phaser.Signal} onOutOfBounds - This signal is dispatched when the parent leaves the world bounds (only if Sprite.checkWorldBounds is true).
*/
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,
/**
* @property {Phaser.Signal} onEnterBounds - This signal is dispatched when the parent returns within the world bounds (only if Sprite.checkWorldBounds is true).
*/
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
/**
* @property {Phaser.Signal} onInputOver - This signal is dispatched if the parent is inputEnabled and receives an over event from a Pointer.
*/
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,
/**
* @property {Phaser.Signal} onInputOut - This signal is dispatched if the parent is inputEnabled and receives an out event from a Pointer.
*/
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,
/**
* @property {Phaser.Signal} onInputDown - This signal is dispatched if the parent is inputEnabled and receives a down event from a Pointer.
*/
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,
/**
* @property {Phaser.Signal} onInputUp - This signal is dispatched if the parent is inputEnabled and receives an up event from a Pointer.
*/
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,
/**
* @property {Phaser.Signal} onDragStart - This signal is dispatched if the parent is inputEnabled and receives a drag start event from a Pointer.
*/
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,
/**
* @property {Phaser.Signal} onDragStop - This signal is dispatched if the parent is inputEnabled and receives a drag stop event from a Pointer.
*/
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
/**
* @property {Phaser.Signal} onAnimationStart - This signal is dispatched when the parent has an animation that is played.
*/
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,
/**
* @property {Phaser.Signal} onAnimationComplete - This signal is dispatched when the parent has an animation that finishes playing.
*/
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,
/**
* @property {Phaser.Signal} onAnimationLoop - This signal is dispatched when the parent has an animation that loops playback.
*/
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
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
var backing = 'this._' + prop;
var dispatch = prop + '$dispatch';
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
// `new Function(string)` is ugly but it avoids closures and by-string property lookups.
// Since this is a [near] micro-optimization anyway, might as well go all the way.
/*jslint evil: true */
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
// The accessor creates a new Signal (and so it should only be used from user-code.)
Object.defineProperty(Phaser.Events.prototype, prop, {
get: new Function("return "+backing+" || ("+backing+" = new Phaser.Signal())")
});
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 dispatcher will only broadcast on an already-defined signal.
Phaser.Events.prototype[dispatch] =
new Function("return "+backing+" ? "+backing+".dispatch.apply("+backing+", arguments) : null");
}