MSPointer.event now stores the most recent pointer event.
MSPointer.pointerDownCallback, pointerMoveCallback and pointerUpCallback all allow you to set your own event based callbacks.
Correct comments:
-Phaser.Camera: checkWorldBounds =>checkBounds
-Phaser.RetroFont: Set correct @name for name and smoothed
-Phaser.DOM: inViewport => inLayoutViewport
BitmapData.copy `tx` parameter if `null` and `source` is a Display Object, it will default to `source.x`.
BitmapData.copy `ty` parameter if `null` and `source` is a Display Object, it will default to `source.y`.
Line.normalX and Line.normalY contain the x and y components of the left-hand normal of the line.
Line.fromAngle will sets this line to start at the given `x` and `y` coordinates and for the segment to extend at `angle` for the given `length`.
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 `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.)
This replaces 'eval' with closures (that should have probably
been used to begin with) to avoid warnings generated by some tools.
This change does not affect the approach used.
- Ref. #1494
- 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
Per https://github.com/photonstorm/phaser/issues/1457 the `sow` function
terminates too early on certain false-y values including 0 (and possibly
"").
This changes that, so that 1) only `undefined` and `null` will terminate
the seed sequence processing (this is to maximize backwards compatibility)
and 2) the `length` of the array is honored.
The documentation also reflects the old (and new/altered) behavior.
This is very minor breaking change; hopefully such is mitigated with
leaving in the null/undefined termination.
- This change uses a secondary canvas and rectangle clearing instead of a
'copy' composition on the same canvas. This should hopefully address
the flickering issue in Safari and Safari Mobile
- 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.
- 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.
- Corrected off-by-one issue; the effect is the same but it is arguably
more correct.
- Fixed getRandomItem; it would previously return null for false'y values
(false/''/0) which was against the defined contract.
- Updated documentation / documented types
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`.
Previously XHD was special-cased for 'json' file assets, but not all JSON
requests. Now it is used for all XHR transfers when `useXDomainRequest` is
enabled.
If XDR is used outside of IE 9 then a warning is emitted to the console.
The `useXDomainRequest` property has also been deprecated
This may address consistency issues as mentioned in
https://github.com/photonstorm/phaser/issues/1361
Some minor cleanup of font component handling and comments.
Also adds a warning if an "unparsable font" string is encountered. Might
save someone some trouble.
Fulfills: https://github.com/photonstorm/phaser/issues/1370
This allows `fontSize` and `fontWeight` to be specified as part of the
style as supplied to the Text constructor (and `setStyle` method). In
addition the `fontStyle` and `fontVariant` properties can also be set -
although these are not exposed later.
This also fixes edge cases that could be caused if `Text#fontSize` was
used without `Text#fontWeight`, where the applied style defaults would be
overwritten/reset.
- Removed `Time.pausedTime`
Time.pausedTime has not been used / updated since
b255fea85f in Feb 2014.
There might be a case to re-explore how pause time is
reported/observable, possibly with a distinction of 'current' and 'last'
and the semantics of such. For instance, pause duration is only updated
after the resume occurs and reflects the duration-of-the-last-pause..
- Removed `Time` _i and _len properties These are better suited by local
variables.
- General documentation updates.
- Marked several methods such as `Timer.order` as protected - there are
advanced use-cases for them, but different user-facing methods and
documentations are likely in order. Also marked `Timer.sortHandler` as
private; but did not change any interfaces.
Addresses https://github.com/photonstorm/phaser/issues/1371 - where Tiled
used floor calculations and Phaser used round calculations.
There are no breaking changes with the demos; however, if there was code
that relied on behavior that _deviated_ from the defactor Tilemap behavior
then may be prone to "incorrect results" if using tileset images that are
not correctly aligned to tilesize multiples.
This also adds/corrects some warnings:
- A warning when the tileset size is not an even multiple (it was
suppressed due to using `round` prior to the checks.
- A warning if loading an image changes the cols/rows of a Tileset
- A specific warning for Tileset Image Collections which are not yet
supported
- Removed previous elapsed/elapsedMS deprecation as they act differently
when the game has been resumed, assuming that it has been properly
paused.
- Refined documentation
- Moved a few properties for better logical grouping
- Annotated timeToCall and timeExpected as protected
- 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.
- Updating documentation for clarity, esp. wrt the now / elapsed /
physicsTime.
- Marked elapsedMS as deprecated as it is just elapsed based on Date.now
instead of the high-res timer; both provide roughly equivalent behavior,
with elapsedMS just falling back to worse-case behavior.
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.
- Cleaned up abnormal case handling
- Disabled parallel loading by default; it can be enabled with
`enableParallel`.
- Minor quibbles
- Removed unused `dataLoadError`
Loaded/loading assets are skipped if they have been superceded. This makes
the behavior consistent with respect to `addToFileList`, if the queue is
inspected or modified while loading.
- Added `withSyncPoint` and `addSyncPoint` methods to allow explicit
adding of synchronization points (synchronization points are explained
in `withSyncPoint`.
- Changed the file/asset `sync` attribute to `syncPoint` to reflect
terminology.
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
Employee the use of image.complete and a width/height check to detect when
it is available "from cache" and skip having to run though the
onload/onerror cases.
Parallel loading is now supported, configured by
`loader.concurrentRequestCount`. Each file (a pack is now considered a
type of file) asset can be marked with `sync`, which is done for both pack
files and script files.
When a `sync` asset is encountered it must be loaded before any previous
resource any following resource is loaded (but it doesn't have to wait for
previous resources). Pack files are an exception in that they can download
(but are not processed) and they can fetch-around other `sync` assets.
Because of the concurrent nature there is no guarantee of the order in
which the individual events will file in relation to eachother, but local
ordering (e.g. onFileError always before onFileComplete) and overall
ordering (e.g. onLoadStart .. onFile? .. onLoadComplete) is preserved.
There is also increased error hardening and a few previous edge-cases
fixed (and likely a few bugs added).
Keyboard.justReleased has bee renamed to Keyboard.upDuration which is a much clearer name for what the method actually does.
Keyboard.downDuration, Keyboard.upDuration and Keyboard.isDown now all return `null` if the Key wasn't found in the local keys array.
Calling justPressed or justReleased on Phaser.Keyboard throws an exception. Changed to reflect new method names in Phaser.Key
I imagine you'd want these methods renamed as well, but it appears to be called by a few other classes and I didn't want a huge pull-request.
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
No breaking changes.
- Fixed jsdoc error `*[]` with documentation
- Also corrected documentation to align with behavior and changed
`callback` to `key` in callAll for consistency
