Every Plugin has been updated to correctly follow the same flow through the Scene lifecycle. Instead of listening for the Scene 'boot' event, which is only dispatched once (when the Scene is first created), they will now listen for the Scene 'start' event, which occurs every time the Scene is started. All plugins now consistently follow the same Shutdown and Destroy patterns too, meaning they tidy-up after themselves on a shutdown, not just a destroy. Overall, this change means that there should be less issues when returning to previously closed Scenes, as the plugins will restart themselves properly.
A note regarding the feature `startAt` of `TimerEvent `
When an event gets added it should be either scaled by clock `timeScale`
as well or not scaled at all - depending on the feature purpose.
```javascript
// preUpdate loop
event.elapsed = event.startAt * event.timeScale
```
In my understanding it should not be influenced by `timeScale` at all.
As a developer I would use the feature of `startAt` to specify the exact
offset for my event.
In case I have looped `Timer` for one second and want to start the first
loop in the middle, I would set the `startAt` to half a second. And
scaling is applied during the timer run time as a factor of speed it
elapses.
In any game that handles fps issues as seen in http://phaser.io/examples/v2/time/slow-down-time the game will hang if game.fpsProblemNotifier fires early on, before game.time.suggestedFps has any value other than null.
The docs recommend waiting a few seconds before accesing suggestedFps. Since it's hard to tell exactly how long "a few seconds" is, shouldn't suggestedFps be initialized to the same value as desidedFps?
I think it's better to get an inaccurate value for a few frames than an invalid value. It means users don't have to care about the specifics of how and when suggestedFps gets its value.
Time.desiredFpsMult is a pre-calculated multiplier used in Game.update.
Time.refresh updates the `Time.time` and `Time.elapsedMS` values and is called automatically by Game.update.
Time.physicsElapsed and Time.physicsElapsedMS are no longer calculated every frame, but only when the desiredFps is changed.
Time.update has been streamlined and the `updateSetTimeout` and `updateRAF` methods merged and duplicate code removed.
- Bypasses issue of usage incorrectly omitting 2nd argument to `splice`
- More clear of intent; `slice` does not modifify `arguments`
- `slice` is faster across all desktop browsers, by varying degrees
- Probably due to parameter-aliasing and de-opts when modified.
- Both `slice` and `splice` create a new Array object
