* Device.edge is a boolean that is set if running under the Microsoft Edge browser.
* Device.dolby is a boolean that is set if the browser can play EC-3 Dolby Digital Plus files
* The Loader and SoundManager can now play Dolby Digital Plus files on supported devices.
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.
Device.h264Video indicates if the browser can play back H264 (mp4) video files.
Device.mp4Video indicates if the browser can play back H264 (mp4) video files.
Device.webmVideo indicates if the browser can play back webm video files with the vp8 codec.
Device.vp9Video indicates if the browser can play back webm video files with the vp9 codec.
Device.hlsVideo indicates if the browser can play back mpeg video files.
Correct comments:
-Phaser.Camera: checkWorldBounds =>checkBounds
-Phaser.RetroFont: Set correct @name for name and smoothed
-Phaser.DOM: inViewport => inLayoutViewport
The `canvasBitBltShift` detection is updated not to pick up any iOS
browsers. This should eliminate false-positives for Chrome for iOS, eg.
Defaulting to using the double-copy is "safer", even if slightly less
optimal.
(A proper feature check should still be added.)
- Memory optimization of delta-scroll shifting.
- The copy canvas is shared between all TilemapLayers
- The copy is done in segments to reduce the memory usage of the copy
canvas. Currently this is a 1/4 ratio.
- Device has the feature (by browser) check to see if bitblt works
- TilemapLayer will automatically enable the double-copy as needed
- Device.whenReady can be used to override the device value
- While not ideal this fixes most (if not all) of the ScaleManager issue
pointed out in #1400. This issue should be addressed later. As of now,
as an interim fix, this avoids the reported issue entirely (or at least
I have not been able to reproduce it), as well as assorted artifacts
when resizign a window while scaling.
- The is is the 2.1 behavior: In certain cases this can result in the
right or bottom of the Game being cut-off slightly (the width of a
scrollbar) instead of scaled, which is why it was originally changed.
- 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}
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
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
