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
- 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
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.
