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.
There are no known breaking changes.
- Timer
- Uses standard Math.min/Math.max (it's better 2, 3 items).
- Math
- Updated documentation
- Marked various Math functions as deprecated, proxying as appropriate
- Array-based functions -> ArrayUtils
- RNG-based functions -> Utils
- Updated core-usage
- floor/ceil should not be used (alternatives provided)
- Altered for some equivalencies
- Also fixes some assorted issues
- Marked a few internal functions as private
- Utils
- Moved polyfills to their own file for better visibility
- Moved array functions to ArrayUtils and marked proxies as deprecated
- Created Phaser.ArrayUtils for array-related functions
- polyfills moved to their own file
- Functions given function names
- Added Math.trunc
We have separated the logic and render updates to permit slow motion and time slicing effects. We've fixed time calling to fix physics problems caused by variable time updates (i.e. collisions sometimes missing, objects tunneling, etc)
Once per frame calling for rendering and tweening to keep things as smooth as possible
Calculates a `suggestedFps` value (in multiples of 5 fps) based on a 2 second average of actual elapsed time values in the `Time.update` method. This is recalculated every 2 seconds so it could be used on a level-by-level basis if a game varies dramatically. I.e. if the fps rate consistently drops, you can adjust your game effects accordingly.
Game loop now tries to "catch up" frames if it is falling behind by iterating the logic update. This will help if the logic is occasionally causing things to run too slow, or if the renderer occasionally pushes the combined frame time over the FPS time. It's not a band-aid for a game that floods a low powered device however, so you still need to code accordingly. But it should help capture issues such as gc spikes or temporarily overloaded CPUs.
It now detects 'spiralling' which happens if a lot of frames are pushed out in succession meaning the CPU can never "catch up". It skips frames instead of trying to catch them up in this case. Note: the time value passed to the logic update functions is always constant regardless of these shenanigans.
Signals to the game program if there is a problem which might be fixed by lowering the desiredFps
Time.desiredFps is the new desired frame rate for your game.
Time.suggestedFps is the suggested frame rate for the game based on system load.
Time.slowMotion allows you to push the game into a slow motion mode. The default value is 1.0. 2.0 would be half speed, and so on.
Time.timeCap is no longer used and now deprecated. All timing is now handled by the fixed time-step code we've introduced.
