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
- Updated `readOnly` doclet to `readonly`
- `array` refined to `type[]`, where such information was immediately
determinable.
- Updated {Any}/{*} to {any}; {...*} is standard exception
- Udated {Object} to {object}
- Removed `Time.pausedTime`
Time.pausedTime has not been used / updated since
b255fea85f in Feb 2014.
There might be a case to re-explore how pause time is
reported/observable, possibly with a distinction of 'current' and 'last'
and the semantics of such. For instance, pause duration is only updated
after the resume occurs and reflects the duration-of-the-last-pause..
- Removed `Time` _i and _len properties These are better suited by local
variables.
- General documentation updates.
- Marked several methods such as `Timer.order` as protected - there are
advanced use-cases for them, but different user-facing methods and
documentations are likely in order. Also marked `Timer.sortHandler` as
private; but did not change any interfaces.
- Removed previous elapsed/elapsedMS deprecation as they act differently
when the game has been resumed, assuming that it has been properly
paused.
- Refined documentation
- Moved a few properties for better logical grouping
- Annotated timeToCall and timeExpected as protected
- Updating documentation for clarity, esp. wrt the now / elapsed /
physicsTime.
- Marked elapsedMS as deprecated as it is just elapsed based on Date.now
instead of the high-res timer; both provide roughly equivalent behavior,
with elapsedMS just falling back to worse-case behavior.
