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.
