Commit graph

150 commits

Author SHA1 Message Date
Richard Davey
173652ea2b Time Types 2019-05-09 12:39:52 +01:00
Richard Davey
6a2397bbae The Clock.now property value is now synced to be the TimeStep.time value when the Clock plugin boots and is no longer Date.now() until the first update 2019-03-26 14:35:14 +00:00
Richard Davey
4fc817c519 Final batch of typedefs 2019-02-13 16:06:00 +00:00
J.C
cff904d74b doc fix: wrong argument type 2019-01-25 11:00:40 +08:00
Richard Davey
bc962c25dc All listeners use the new Events 2019-01-18 13:41:43 +00:00
Richard Davey
aa341854c7 Happy New Year 2019-01-15 16:20:22 +00:00
Richard Davey
12bcdbf672 Docs fix 2018-10-25 16:26:34 +01:00
Richard Davey
4c4421c47f Docjam merge 2018-10-19 12:32:43 +01:00
Richard Davey
4b1c762296 Updated @memberOf to @memberof 2018-10-10 10:49:13 +01:00
Richard Davey
a9063604dc Replace @readOnly with @readonly 2018-10-09 13:40:00 +01:00
Richard Davey
5fe6dbbe0c Added more jsdocs 2018-09-13 08:09:44 +01:00
Richard Davey
7aa46657c2 Tidying up jsdocs and changing float to number 2018-06-26 23:19:14 +01:00
Richard Davey
350cb037b7 All systems now register themselves with the new PluginCache 2018-05-15 12:51:50 +01:00
Richard Davey
be330e609e Moved PluginManager to new location 2018-05-10 17:14:33 +01:00
Richard Davey
1be486fab4 destroy only called once, no matter how many times the Scene restarts. Fix #3581 2018-04-17 12:25:45 +01:00
Richard Davey
ce7d67297f Moving from 3.4.1 to 3.5.0 so we can release new camera fx and scene transitions 2018-04-15 12:44:47 +01:00
Richard Davey
6b2307594a Scene plugin flow overhaul
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.
2018-04-13 17:12:17 +01:00
orblazer
ed1f2a7011 Fix wrong types 2018-03-22 13:51:30 +01:00
orblazer
90cf919b10 Fix "object" types on Sound and Time 2018-03-21 15:02:10 +01:00
orblazer
cb708dcc32 Update JSDoc on Textures, Tilemaps and Time 2018-03-19 02:03:17 +01:00
migiyubi
174c982966 Fix TimerEvent.remove behaves opposite to what we expect 2018-03-09 19:47:45 +09:00
Richard Davey
d23688c3e4 Added eslint fixes and overrides 2018-02-16 18:44:07 +00:00
Richard Davey
e1554c34d6 eslint fixes 2018-02-16 18:07:49 +00:00
Richard Davey
2813ac8162 Moved PluginManager and merged configs into single root file for easier changing. 2018-02-12 23:03:48 +00:00
Richard Davey
d1f5f8a82b Added jsdocs 2018-02-12 16:01:21 +00:00
Richard Davey
502ebf7068 Added jsdocs 2018-02-10 02:31:42 +00:00
Richard Davey
40689d1e35 Updated jsdocs. 2018-02-07 15:27:21 +00:00
Richard Davey
d9227420b3 Added jsdocs 2018-02-06 01:22:22 +00:00
Richard Davey
2a86400a28 Added in jsdocs 2018-01-31 13:54:44 +00:00
Artem Platonov
3e5a35d796 TimerEvent startAt field not scaled
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.
2018-01-23 16:34:33 +01:00
Artem
2bf0381821
clock timescale applied to timer 2018-01-23 14:37:25 +01:00
Richard Davey
2deb9edc9e Plugins now check to see if the Scene is already booted and adapt accordingly. 2018-01-18 14:00:31 +00:00
Richard Davey
5a333bc2fd Updated to new Plugin format, removed injection and mapping 2018-01-18 05:18:09 +00:00
Richard Davey
4240f6c4af Converted to use the new plugin format 2018-01-16 02:08:22 +00:00
Richard Davey
d8f1ba03e9 Moved repository location 2018-01-09 21:43:56 +00:00
Richard Davey
0d90f75b5f Splitting the dev branch up into versions. 2016-11-22 01:36:56 +00:00
Richard Davey
4548d70369 Experimenting with new MainLoop + position interpolation. (reverted from commit e49d45e278) 2016-07-13 02:44:35 +01:00
Richard Davey
e49d45e278 Experimenting with new MainLoop + position interpolation. 2016-07-12 03:05:29 +01:00
Sean Irby
3c2003365d Update docstring for TimerEvent
I think the TimerEvent lifecycle could use some clarification so I updated the docstring to explain what happens when they are finished firing.
2016-06-02 17:47:31 -07:00
photonstorm
7afe087c3d Docs fix. 2016-04-29 17:46:44 +01:00
photonstorm
f40cfbe2ae 2015 - 2016. 2016-04-04 22:16:16 +01:00
thiagojobson
58817869dc Fixed links in documentation 2016-03-25 18:08:29 -03:00
photonstorm
79d6993f26 Fixed issue with Time.update not being properly set in IE9 / setTimeout environments. 2015-10-13 14:23:36 +01:00
Richard Davey
5f704f0b0f Merge pull request #2130 from noidexe/patch-5
Better default value for suggestedFps
2015-10-13 13:47:15 +03:00
Lisandro Lorea
dea95ec6f6 Better default value for suggestedFps
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.
2015-10-09 16:14:52 -03:00
Paul
9733fb4ec2 Updated documentation to clarify 'types' of time
- Added 'Types of time' description and cross-links
- Also some general documentation update for Timer
  - Type specialization

Ref #2088
2015-09-14 20:21:47 -07:00
photonstorm
a8e972b25a Under setTimeOut (or when forceSetTimeOut was true) the Time was incorrectly setting Time.timeExpected causing game updates to lag (thanks @satan6 #2087) 2015-09-14 16:31:16 +01:00
photonstorm
816bcaca75 Missing physicsElapsed value reset. 2015-09-10 16:05:15 +01:00
photonstorm
90a500ec1e Game.update could call updateLogic multiple times in a single frame when catching up with slow device frame rates. This would cause Tweens to advance at twice the speed they should have done (thanks @mkristo)
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.
2015-09-09 12:09:18 +01:00
photonstorm
2de83328d9 Testing Tween timer fix. 2015-09-08 17:44:28 +01:00