Camera.fade is a new function that makes the camera fade to the color given, over the course of the duration specified. This is great for things like transitioning from one State to another. You can listen for the Camera.onFadeComplete Signal.
Camera.resetFX resets any active FX, such as a fade or flash and immediately clears it. Useful to calling after a fade in order to remove the fade from the Stage.
Phaser.Camera.ENABLE_FX is a const that controls if the Camera FX are available or not. It's `true` by default, but if you set it to `false` before boot then it won't create the Graphics object required to process the effects.
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.
Group.getFirstDead, Group.getFirstAlive and Group.getFirstExists all have new optional arguments: `createIfNull`, `x`, `y`, `key` and `frame`. If the method you call cannot find a matching child (i.e. getFirstDead cannot find any dead children) then the optional `createIfNull` allows you to instantly create a new child in the group using the position and texture arguments to do so. This allows you to always get a child back from the Group and remove the need to do null checks and Group inserts from your game code. The same arguments can also be used in a different way: if `createIfNull` is false AND you provide the extra arguments AND a child is found then it will be passed to the new `Group.resetChild` method. This allows you to retrieve a child from the Group and have it reset and instantly ready for use in your game without any extra code.
- 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
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.
Sprites with Arcade Physics bodies that had `collideWorldBounds` enabled would be moved to the wrong position if you restarted a State (or swapped to a new State) that reset the world bounds (thanks @vulvulune #1775)
Phaser.StateManager.created is a new read-only boolean that tells you if the State has finished running its `create` method. If it doesn't have one it's always true.
The StateManager would incorrectly call `loadRender` while the game was paused or if the State didn't have an `render` method defined even after the loader was completed.
Group.physicsSortDirection is a new property allowing you to set a custom sort direction for Arcade Physics Sprites within the Group hash. Previously Arcade Physics used one single sort direction (defined on `Phaser.Physics.Arcade.sortDirection`) but this change allows you to specifically control how each and every Group is sorted, so you can now combine tall and wide Groups with narrow and thin in a single system.
Loader.onLoadComplete is dispatched *before* the Loader is reset. If you have a `create` method in your State please note that the Loader will have been reset before this method is called. This allows you to immediately re-use the Loader without having to first reset it manually.
Correct comments:
-Phaser.Camera: checkWorldBounds =>checkBounds
-Phaser.RetroFont: Set correct @name for name and smoothed
-Phaser.DOM: inViewport => inLayoutViewport
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.
- Clarified proper usage of `pageAlignVertically` and add note about 2.2
change and how to obtain 2.1 behavior.
- Removed the `@readonly` status of the `parentIsWindow` and `parentNode`;
these can be updated in a controlled manner.
- Added intra-hyperlinks
- Updated some ancillary documentation
The click trampoline added for IE prevents Chrome for Android from being
able to launch Full Screen mode with the default parameters for
`ScaleManger#startFullScreen`. (The desktop version of Chrome is not
affected.)
This fix adds an additional compatibility settings (`clickTrampoline`)
that can be used to configure when such is used. By default the
'when-not-mouse' mode is only enabled for Desktop browsers, where the
primary input is ubquitously a mouse.
There are no known breaking compatibility changes - the Full Screen should
be initiatable in Chrome for Android as it was in 2.1.x. The default
Android browser does not support Full Screen.
As pointed out, `newChild.parent` could be accessed after it was set to
undefined. This fix unifies the code from the various `destroy` methods so
the previou issue does not occur.
There are a bunch of signals added for Sprites; more when input is
enabled. However, very few of these signals are ever actually used. While
the previous performance update related to Signals addressed the size of
each Signal object, this update is to reduce the number of Signal objects
as used by the Events type.
As a comparison the "Particle: Random Sprite" demo creates 3200+ Signals;
with this change there less than 70 signals created when running the same
demo. (Each Event creates at 8 signals by default, and there is an Event
for each of the 400 particles.) While this is an idealized scenario, a
huge amount (of albeit small) object reduction should be expected.
It does this by creating a signal proxy property getter and a signal
dispatch proxy. When the event property (eg. `onEvent`) is accessed a new
Signal object is created (and cached in `_onEvent`) as required. This
ensures that no user code has to perform an existance-check on the event
property first: it just continues to use the signal property as normal.
When the Phaser game code needs to dispatch the event it uses
`event.onEvent$dispath(..)` instead of `event.onEvent.dispatch(..)`. This
special auto-generated method automatically takes care of checking for if
the Signal has been created and only dispatches the event if this is the
case. (If the game code used the `onEvent` property itself the event
deferal approach would be defeated.)
This approach is designed to require minimal changes, not negatively
affect performance, and reduce the number of Signal objects and
corresponding Signal/Event resource usage.
The only known user-code change is that code can add to signal (eg.
onInput) events even when input is not enabled - this will allow some
previously invalid code run without throwing an exception.
- 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}
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.
There are a fair amount of Signal objects created. In the current
implementation these are somewhat "fat" objects for two reasons:
- A closure / ad-hoc `dispatch` is created for each new Signal - this
increases the retained size by 138+ bytes/Signal in Chrome.
- There are a number of instance variables that never change from their
default value, and the bindings array is always created, even if never
used.
This change "lightens" the Signals such that there is significantly less
penalty for having many (unusued) signals.
As an example of how much this _does_ play a role, in the "Random Sprite"
demo ~2000 Signals are created, with only 12 of these signals being
subscribed to. This results in a shallow size of ~300K and a retained size
of ~600K (which is almost as much memory as required by the
Sprites/Sprites themselves!) for .. nothing.
With these changes the shallow and retained sizes are less than 50K each -
and this is with only ~200 sprites!
This change addresses these issues by
- Changing it so there is _no_ `dispatch` closure created. This is a
_breaking change_ (although there is no usage of such in core where it
breaks); the code referenced "#24", but no such issue could be found on
github.
In the rare case that code needs to obtain a dispatch-closure, the
`boundDispatch` property can be used to trivially obtain a (cached)
closure.
- The properties and default values are moved into the prototype; and the
`_bindings` array creation is deferred. This change, coupled with the
removal of the automatic closure, results in a very lightweight
~24bytes/object (in Chrome) for unbound signals.
This is minor breaking change, as per the removal of the automatic
closure; but no such need/usage was found in the core. (There may be cases
in the examples, which were not checked.)
If merely opting for the array creation delay and keeping the default
properties in the prototype the shallow size is still halved; less
significant but still a consideration.
This de-optimization occurred between 2.0.7 and 2.1.0 and is currently
present through dev.
`Group.forEach`, which is used by QuadTree, had an extreme de-optimization
in assigning to `arguments` - _CPU profiling showed as much as 50% of the
time was used by Group.forEach_ (after the correction it is not
registered) due to this de-optimization making the "When Particles
Collide" demo run with an unsatisfactory performance, even on a Desktop.
The fix uses a separate array and push (which is optimizable; the previous
implementation was not optimizable in Chrome, FF, or IE!).
This also fixes usages of `slice(arguments,..); ushift` elsewhere in
Group, using the same convention. It applies the same update for `iterate`
as does https://github.com/photonstorm/phaser/pull/1353 so it can also
accept null/undefined for `args` from the invoking functions.
Update iterate documentation to cover usage of `args` and added a guard so
that the callback can be used without requiring that `args` is specified.
Ref. https://github.com/photonstorm/phaser/issues/1352
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
ScaleManager.windowContraints now allows specifing 'visual' or 'layout' as
the constraint. Using the 'layout' constraint should prevent a mobile
device from trying to resize the game when zooming.
Including the the new changes the defaults have been changed to
windowContraints = { right: 'layout', bottom: '' }
This changes the current scaling behavior as seen in "Game Scaling" (as it
will only scale for the right edge) but also prevents such scaling from
going wonkers in some mobile environtments like the newer Android browser.
(Automatic scroll-to-top, albeit configurable, enabled for non-desktop by
default is not a fun situation here.)
To obtain the current semantics on a desktop the bottom should be changed
to 'layout'; although this will result in different behavior depending on
mobile device. To make the sizing also follow mobile zooming they should
be changed to 'visual'.
Also added temp Rectangle re-used for various internal calculations.
---
Phaser.DOM now also special-cases desktops to align the layout bounds
correctly (this may disagree with CSS breakpoints but it aligns the with
actual CSS width), without applying a window height/width expansion as
required on mobile browsers.
(And the jshint error isn't mine..)
"Final" changes for a solid 2.2-worthy ScaleManager.
This adds in official support for USER_SCALE, which allows a flexible way
to control the scaling dynamically.
It fixes a visible display bug in desktop browsers (viewport clipping was
off) and mitigates some potential issues all around by using a unified
visualBound calculations in Phaser.DOM.
It applies some protected/deprecated attributes, but does not remove any
behavior of already-established (as in, outside-dev) means.
There are no known [signficant] breaking changes; any known breaks (not
considered fixes) are constrained to dev with no known consumers.
Phaser.DOM
There are no known significant breaking changes; Phaser.DOM was
internal.
- Added visualBounds; this should be the true visual area, minus the
scrollbars. This should be used instead of clientWidth/clientHeight to
detect the visual viewport.
- Expose various viewport sizes as dynamically updated properties on
Rectangle objects. These are visualBounds, layoutBounds,
documentBounds.
- Updated documentation the different bounds; in particular drawing
distinction between viewport/layout bounds and visual bounds.
- Renamed `inViewport` to `inLayoutViewport` to indidcate behavior.
- Minor breaking, but dev-only
- Changed `getAspectRatio` to work on Visual viewport. This will yield
the expected behavior on mobiles.
- Minor breaking, but dev-only
- Removed some quirks-mode and legacy-browser special casing
Phaser.ScaleManager
There are no known significant breaking changes.
- USER_SCALE is 'made public'. It can used to flexibly configure any
custom-yet-dynamic scaling requirements; it should now be able to
replace any sane usage of manual sizing invoking the deprecated
setSize/setScreenSize.
- Added additional usage documentation and links to such
- Added the ability to specify a post-scale trim factor.
- Change the arguments the resize callback and document what is passed
- Minor breaking, but the previous arguments were undocumented
- `compatiblity.showAllCanExpand` renamed to `canExpandParent` and made
generalized over possibly-expanding scaling.
- Minor breaking, dev-only, for coding changing this settin
- Switched from direct usage of of window innerWidth/Heigth to
Phaser.DOM visualViewport - this change correctly accounts for
scrollbars in desktop environments
- Although it does slightly alter the behavior, this is a fix.
- Removed usage of window outerWidth/outerHeight which didn't make much
sense where it was used for desktops and was catostrophic for mobile
browser
- Although it may slightly alter the behavior, this is a fix.
- Removed `aspect` and `elementBounds` because they are duplicative of
Phaser.DOM (which can not be accessed as `scale.dom`).
- Minor breaking, but internal methods on dev-only
- Marked the minWidth/maxWidth/minHeight/maxHeight properties as
protected. They are not removed/obsoleted, but should be revised later
for more flexibility.
- Orientation handling; non-breaking forward deprecations
- Added `onOrientationChange` and deprecated the 4 separate leave,
enter, landscape and portrait signals. They are not removed, so this
is a future-migration change.
- Fixed issue where state not updated prior to callback
- Fixed issue where orientation callbacks were not always delayed
- Fullscreen events: non-breaking forward deprecations
- Added `onFullScreenChange` and deprecated `enterFullScreen` and
`leaveFullScreen`.
- Renamed (with proxy) `fullScreenFailed` to `onFullScreenError`.
Phaser.Device
- Improved `whenReady` to support Phaser.DOM better
- Allows a ready handler to be added without starting the
device-detection proccess. This allows it to be registered to
internally (eg. from System.DOM) without affecting current behavior.
- Passes the device object as the first parameter to the callback
function.
- Fixed code where Silk detection not applied to `desktop` detection.
Manifest: System.Device moved before System.DOM
- Added `onFullScreenInit` signal which is the correct place for a client
to alter the FS target element, such as to set a background color or add
a CSS class.
- Increased documentation overview and specificity including expected
Parent behavior, sizing calculations, and when `refresh` may be required.
- Grouped documentation for scale modes (in 'scaleMode')
- Separated out internal/deprecated `setScreenSize` method from
`updateLayout`.
There are no known breaking changes.
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
- Renamed ArrayList to ArraySet
- Added ArrayList is a deprecated proxy for compatibility
- Updated internal code to use ArraySet
- ArraySet can be constructed with an array; if the caller is willing to
accept some responsibility this can remove the O(n^2) behavior of
repeatedly calling `add`.
- Updated Group.filter to take advantage of this
- ArraySet.total is read-only proxy for for list.length
- Fixes ArraySet.setAll where it would only set properties with truthy
values
- Updated 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>
No known breaking changes - as it's still dev/internal stuff.
- Added Phaser.DOM to house new DOM functions, moved stuff
over from ScaleManager as appropriate
- Fixed a fiew cases of missing functions
- Changed some of the new signatures to protected for the interim.
(Maybe a `beta` tag would fit better? Public is promises!)
- Moved generic support from Canvas to DOM and added proxy/notes
- Updated internal usages
- Updated some comments for consistency
- Access always on bottom for members/properties, public assumed
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
- Added `compatibility` settings
- CHANGE (2.1.2-4): moved `supportsFullScreen` and `noMargins` into it
- Added additional properties for greater control and up-front settings.
- `scrollTo`: where the browser will scrollTo, if anywhere
- `forceMinimumDocumentHeight`: apply document element style?
- `allowShowAllExpand`: allow SHOW_ALL to try to expand? (It already
could, this allows configuration.)
- Removed `windowConstraints.top/left`. This may be a feature in the
future, but scrubbed for now.
- Added `USER_SCALE` scale mode. This is like NO_SCALE but it scales off
of a user-specified scale factor, as set by `setUserScale`. This is
marked as "experimental" as the exactly semantics of non-adjusting modes
(e.g. NO_SCALE and USER_SCALE) wrt. Canvas and "maximum" size clamps
need to be re-examined.
- FIX: `onSizeChange` now works as documented, which means it is also
fired if the game size changes even though the game canvas size does
not.
- CHANGE (no known breaking): `margins` is now non-Point/non-Rectangle
that uses top/left/bottom/right properties (any quasi-updated x/y). This
is to get around the issue that Rectangle is only designed for positive
width/height cases.
- Cleaned up property access / quotes for consistency
- Various documentation cleanup and consistency
- Fixed issue with not clearing an unparented `_createdFullScreenTarget`
- Added Phaser.Rectangle.sameDimensions which does a strict equality check
over the `width` and `height` properties of two objects, perhaps
Rectangles.
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.
ScaleManager.calibrate is a private method that calibrates element coordinates for viewport checks.
ScaleManager.aspect gets the viewport aspect ratio (or the aspect ratio of an object or element)
ScaleManager.inViewport tests if the given DOM element is within the viewport, with an optional cushion parameter that allows you to specify a distance.
ScaleManager.scaleSprite takes a Sprite or Image object and scales it to fit the given dimensions. Scaling happens proportionally without distortion to the sprites texture. The letterBox parameter controls if scaling will produce a letter-box effect or zoom the sprite until it fills the given values.
ScaleManager.viewportWidth returns the viewport width in pixels.
ScaleManager.viewportHeight returns the viewport height in pixels.
ScaleManager.documentWidth returns the document width in pixels.
ScaleManager.documentHeight returns the document height in pixels.
- Adds `ScaleManager#windowContraints`
- In 2.1.3 and prior the scale modes (EXACT_FIT, SHOW_ALL) were actually
based off the window dimensions, even though the parent element did
not correctly reflect this nature.
- When set (the default now is that right and bottom are set) the
behavior will mostly correctly mimic the 2.1.3 (minus bugs) and
before.
- CHANGE (from 2.1.3): The window constraints also affect the RESIZE
mode, arguably this is more consistent.
- To disable this "constrain to window" behavior, simply set the
appropriate property to false, as in:
`game.scale.windowConstraints.bottom = false`
- 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
This includes some minor breaking changes.
- Unifies SHOW_ALL and NO_SCALE being stretched in Firefox and IE
- As suggested by MDN: "..to emulate WebKit's behavior on Gecko, you
need to place the element you want to present inside another
element.."
- This done via an (overwritable) `createFullScreenTarget` function.
The (new) DOM element returned from this is placed into the DOM and
the canvas is added to (and later removed) as the full screen mode
changes.
- MINOR BREAK: may affect code that assumes the Phaser canvas has a
fixed DOM/CSS path (which should hopefully be nobody). To use to the
original behavior, where the canvas is not moved, simply set
`this.fullScreenTarget = game.canvas` manually.
- Updates the refresh/queue to be unified and uses a smarter back-off to
detect and react to parent dimension changes
- Cleans up some odd browser issues; not tried on mobile
- Fixes an issue were update might be called too much and spend time
doing nothing useful.
- `maxIterations` is no longer user and marked as deprecated
- MINOR BREAK: previous approach would occasionally (but not always)
back off updates the entire iteration/setTimeout sequence; under the
new approach "onResize" may be called more frequently.
- Fixes a number various transition issues, mostly around RESIZE
- MINOR BREAK, but correct: leaving RESIZE restores the original game
size possible
- Fixes assorted quirks with scales not being updated
- Layout
- MINOR BREAK: All Canvas margins are "OWNED" by the ScaleManager. They
will be reset in all modes as appropriate. This is for consistency
fixes as well as coping with the updated full screen.
- MINOR BREAK: Canvas right/bottom margins are set to negative margins
to counter left/top margins. This prevents Canvas margin adjustments
from affecting the flow .. much.
- `getParentBounds` rounds to the nearest pixel to avoid "close to"
value propagation from CSS.
- Fixes page-align center pushing canvas out of parent
- Misc.
- MINOR BREAK: `setScreenSize` will update the game size if the mode is
RESIZE. User-code shoulde use `refresh` instead to ensure that any
relevant changes are propagated.
- Corrected incorrect documentation
- Added prefixed event handlers for IE; it still doesn't work in IE, but that is for other reasons
- Added monitoring of the fullscreenerror event, exposed as a fullScreenFailed signal
- Added `supportsFullScreen` a read-only flag that indicates that this ScaleManager even attempts to support such
- Specific bug fixes (example)
- Scale modes can now be set independently
- Switching between fullscreen and normal correctly restores modes
- Alignment does not incorrectly offset in fullscreen mode
- Changing scale/alignment promptly refreshes layout
- `isFullScreen` returns a boolean, as it should
- Faster parent checks (if required)
- NO_SCALE should not not scale (vs previous behavior of having no behavior)
- Correct usage of scaleMode depending on mode
- Removed / unified code-paths, which helped address several issues
- fullScreenTarget adjustment/restoration is less brutal
- Updated documentation
- pageAlign* works as alignment on the containing element. It should still work were it worked before (so this is not a breaking change) as well as being more universal.
- Added @protected and @private attributes
- Some methods were (implicitly) @public even though using them out of context is invalid
- API Breaking:
- Renamed some INTERNAL/@private methods
- Should only affect methods that were not valid/sane to use publically
- Event callbacks (ie. checkResize changed to resizeWindow) renamed for meaning
- Changed some INTERNAL semantics to better align with usage
- eg. `check*` methods separated from response-to-check
