Moved BitmapData and RenderTexture into the textures folder for now.
All Game Objects now have their own sub-folder, with their Factory and renderer functions alongside them, plus any other files they need.
New Factory class added. Currently hooked into `game.factory` for testing, but will swap to `game.add` when complete.
`game.renderer.setTexturePriority` is the method that goes with the Multiple Texture support. It takes an array as its single argument. The array consists of Phaser.Cache image key strings. Phaser will then try to batch as many of the textures as it can, depending on the hardware limits. If for example the GPU can only batch 8 textures, and you provide an array of 16, then only the first 8 in the array will be batched.
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.
Sprite.setTexture has a new `destroyBase` parameter - set this to `true` if you know the base used a generated texture that isn't being used by any other sprites. This will free-up the canvas for further re-use by other calls to generateTexture or Text objects.
Cache.clearGLTextures empties out all of the GL Textures from Images stored in the cache. This is called automatically when the WebGL context is lost and then restored.
This change implements the original suggestion of using `updateTransform`,
but applies so globally instead of within a particular postUpdate
function.
Now the game loop calls `updateTransform` after each `updateLogic` call
unconditionally; it is updates that change the world that are accounted
for, not the rendering. This removes some previous checks that were
preventing correct behavior with the previous patch.
This makes the assumption that game objects (eg. Sprites) are only
modified within callbacks triggered before the completion of the
`postUpdate` walking of the scene graph.
- User code that runs outside of the "game update", such as a `setTimeout`
timer, will need to explicitly update transformations so that the world
is synced by the next `preUpdate`: but this is not the expected case and
is already outside the Phaser update model.
- If this assumption does not hold or is too weak, the transformations
could also be applied once at the start of every game update loop
(before any render or update). This change would at most double the time
spent on apply the transformations.
The constant application of `updateTransform` passes all reported failing
cases and resolves#1424 just as the original proposal of having the
change performed in the Sprite postUpdate but will work more consistently
across all scene-bound game objects.
On a desktop Chrome browser the inclusion also has minimal relative impact
as shown by the summarized results. The percentages given are the summed
CPU time of relevant required operations along with that of the
updateTransform itself:
- 10,000 non-collision particles:
- 12% pre/post update, 2.4% updateTransform
- 100 colliding particles:
- 2% pre/post update & collision, 0.3% updateTransform
- 1000 colliding particles:
- 40% pre/post update & collision, 1% updateTransform
With this patch the updateTransform time does creep up _slightly_ (vs just
in `Sprite.postUpdate`) but it is still dominated by required game
updates, and more so, by any actual work like Physics.
The substraction of `physicsElapsedMS` needs to be done for all individual
updates. (When current FPS ~ target FPS this is a 1-1 mapping, but catchup
updates can throw off the calculations.)
Also renamed `Game#updateNumber` (a poor initial name on my part) to
`currentUpdateID`. This matches the naming of
`Stage#currentRenderOrderID`.
- Changed `count` from 0d9678e512 to
`updateNumber` and expanded documentation; also moved primary usage back
to local variable.
- Added `updatesThisFrame` which allows (logic) code to detect if it is
the last update, or if there are pending updates the same frame. While
it could be adventageous in certain cases it will be problematic if such
update logic relies in the supplied delta time, as such should change if
fixed-timing is deviated from or extended updates are done.
- Formatting and documentation.
When specifying the ease in `Tween.to` or `Tween.from` you can now use a string instead of the Function. This makes your code less verbose. For example instead of `Phaser.Easing.Sinusoidal.Out` and you can now just use the string "Sine".The string names match those used by TweenMax and includes: "Linear", "Quad", "Cubic", "Quart", "Quint", "Sine", "Expo", "Circ", "Elastic", "Back", "Bounce", "Power0", "Power1", "Power2", "Power3" and "Power4". You can append ".easeIn", ".easeOut" and "easeInOut" variants. All are supported for each ease types.
Tweens now create a TweenData object. The Tween object itself acts like more of a timeline, managing multiple TweenData objects. You can now call `Tween.to` and each call will create a new child tween that is added to the timeline, which are played through in sequence.
Tweens are now bound to the new Time.desiredFps value and update based on the new Game core loop, rather than being bound to time calculations. This means that tweens are now running with the same update logic as physics and the core loop.
Tween.timeScale allows you to scale the duration of a tween (and any child tweens it may have). A value of 1.0 means it should play at the desiredFps rate. A value of 0.5 will run at half the frame rate, 2 at double and so on. You can even tween the timeScale value for interesting effects!
Tween.reverse allows you to instantly reverse an active tween. If the Tween has children then it will smoothly reverse through all child tweens as well.
Tween.repeatAll allows you to control how many times all child tweens will repeat before firing the Tween.onComplete event. You can set the value to -1 to repeat forever.
Tween.loop now controls the looping of all child tweens.
Tween.onRepeat is a new signal that is dispatched whenever a Tween repeats. If a Tween has many child tweens its dispatched once the sequence has repeated.
Tween.onChildComplete is a new signal that is dispatched whenever any child tweens have completed. If a Tween consists of 4 sections you will get 3 onChildComplete events followed by 1 onComplete event as the final tween finishes.
Chained tweens are now more intelligently handled. Because you can easily create child tweens (by simply calling Tween.to multiple times) chained tweens are now used to kick-off longer sequences. You can pass as many Tween objects to `Tween.chain` as you like as they'll all be played in sequence. As one Tween completes it passes on to the next until the entire chain is finished.
Tween.stop has a new `complete` parameter that if set will still fire the onComplete event and start the next chained tween, if there is one.
Tween.delay, Tween.repeat, Tween.yoyo, Tween.easing and Tween.interpolation all have a new `index` parameter. This allows you to target specific child tweens, or if set to -1 it will update all children at once.
Tween.totalDuration reports the total duration of all child tweens in ms.
There are new easing aliases:
* Phaser.Easing.Power0 = Phaser.Easing.Linear.None
* Phaser.Easing.Power1 = Phaser.Easing.Quadratic.Out
* Phaser.Easing.Power2 = Phaser.Easing.Cubic.Out
* Phaser.Easing.Power3 = Phaser.Easing.Quartic.Out
* Phaser.Easing.Power4 = Phaser.Easing.Quintic.Out
The only known breaking change is if user-code relied on `device.game` or
manually called `checkFullScreenSupport`, as both have been removed.
- Phaser.Device is now a singleton object that does not belong to a
particular game. The only thing that it belongs to is the window/host
context.
- `game.device` (shared between all games) and `Phaser.Device` are the
same object.
- There is no more `Device#game` property.
- The specific device-ready detection is moved out of Game into the Device
code
- It is possible for multiple Games (or even non-Games) to use
`Device.whenReady`.
- Initialization is done immediately upon device-ready; there is an
onInitialized signal that is dispatched that can be subscribed to
extend the default initialization.
- The fullscreen-detection code (that was the only dependent of game) now
uses an new element.
- Updated jsdoc documentation
- FIX#1306, hopefully, where an orientation change did not correclty
cause a screen/layout update.
- FIX/CHANGE where Paused games would not update the scale
- The new behavior "runs" the ScaleManager in a paused state via
`pauseUpdate`; a User paused game will now correctly track scale
changes. This is closer to the 2.1.3 behavior in some cases, such as
window resizing, when the updates were done in the DOM event.
- This change also affects device orientation change monitoring and
events, which are also deferred to the update cycle
- The update cycle is set to the maximum and is still dependent on the
RAF / primary loop running, so it should not affect background
apps/tabs
- FIX/CHANGE New better backoff timing; ie. continuous window resizing is
limited to ~10 fps update calculations. This makes it much harder to
crash Chrome by rapidly and continously resizing the window. Also
increases the scaling from 0..10..20..40 to 0..25..50..100.
- FIX an issue where the incorrect orientation was "one frame behind" the
scaling.
- UPDATE The contract for when the change orientation events occurs is
better defined - it now always happens in the update context as with
game sizing.
- UPDATE Unifies orientation-change code / handling and duplicate.
- CHANGE Added DOM.getScreenOrientation which obtains the orientation via
the Device Orientation API (WD) and provides comprehensive fallbacks
- This should cover all modern browsers
- FIX: Orientation on desktops now computed as screen ratio by default
which fixesi the false-portrait chain/detection when the page is made
more narrow than it is tall.
- CHANGE/FIX: window.orientation is now only used as fallback, if
requested (due to device differences). It may be appropriate to enable
this (via `scale.compatibility` on boot, for instance) in some
environments.
Signed-off-by: Paul <pstickne@gmail.com>
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.
- Sizing events:
- CHANGE: The `onResize` callback is called only from `preUpdate` (which
may be triggered from a window resize) and it will be called on
refreshes even if the parent size has not actually changed.
- A new `onSizeChange` Signal has been added. It is called _only_ when
the Game size or Game canvas size has changed and is generally more
applicable for performing layout updates.
- Game documentation now links to ScaleManager#setGameSize (which was
renamed from #setGameDimensions)
- Removed extra/legacy full-screen restore code
- Margins:
- Added `noMargins` flag; if set to true the Canvas margins will never
be altered. This also means that
- Margins are now set/cleared individually to avoid conflict with
'margins' style compound property
- Code consistency updates
- NOTE: Changing `game.width/game.height` via user code was always
problematic. This commit updates the documentation for such members as
read-only. The only supported way to change the GAME SIZE after it is
created is to use `ScaleManager#setGameDimensions`, which has been
added.
- The GAME SIZE will be reset to the initial (or as set by
`setGameDimensions`) values upon changing the scale mode or
entering/leaving full screen. This may be a breaking from 2.1.2 (but
many mode changes acted oddly prior).
- SHOW_ALL will now EXPAND it's parent container if it can. As per
@tjkopena 's notes, this should more closely represented the expected
behavior.
- SHOW_ALL will first try to expand by the OVERFLOW AXIS and then
attempt to resize to fit into the possibly larger area; use the
parent's max-height/max-width properties to limit how far SHOW_ALL can
expand.
- RE-BREAKING: This changes the behavior from 2.1.4 and makes it more like
2.1.3, with fixes.
- As per previous commit the ScaleManager _owns_ the margins and size of
the GAME CANVAS. To control the dimensions of the GAME CANVAS, use the min/max
height/width of the parent. Setting padding on the parent is _NOT_
supported.
- Fixes various issues with switching between Scale Modes
The width and height given to the Phaser.Game constructor can now be numbers or strings in which case the value is treated as a percentage. For example a value of "100%" for the width and height will tell Phaser to size the game to match the parent container dimensions exactly (or the browser window if no parent is given). Equally a size of "50%" would tell it to be half the size of the parent. The values are retained even through resize events, allowing it to maintain a percentage size based on the parent even as it updates.
Stage.offset has been moved to ScaleManager.offset
Stage.bounds has been removed, you can access it via Stage.getBounds.
Stage.checkOffsetInterval has been moved to ScaleManager.trackParentInterval
ScaleManager.hasResized signal has been removed. Use ScaleManager.setResizeCallback instead.
StateManager.clearCurrentState now handles the process of clearing down the current state and is now called if the Game is destroyed.
Game.destroy now clears the current state, activating its shutdown callback if it had one. It also now destroys the SoundManager, stopping any currently running sounds (#1092)
Input.Gamepad.destroy now destroys all connected SinglePads and clears event listeners.
SinglePad.destroy now clears all associated GamepadButton objects and signals.
A slightly obnoxious but necessary hack to prevent a race condition between the loading of Apache Cordova and Phaser itself.
Without waiting for the 'deviceready' event, Phaser can often load first, preventing any console messages from appearing to the user. Because Cordova writes to the platform's console (via CordovaLog), it must first be loaded and signal its own 'deviceready' event before console or plugin usage can occur. Otherwise, all messages and functionality is ignored.
If pause is called manually, codePaused should be set regardless of whether the game is currently paused or not. This would fix issues where a developer might not want the game to automatically resume when the screen regains focus.
