New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code improvement suggestion for angleBetween() method #2463
Comments
I know what you're talking about because I've just run into the same problem. However, there is no worldX/worldY property on sprites (although there are on pointers). Sprites are always positioned relative to their parents. If you use Phaser.Math.angleBetween, you run into the same problem when using it between a pointer and sprites that are children of other sprites (and not the game world). And getting the actual world x/y on child sprites (especially child sprites of child sprites) is really a huge pain in the ass. I've had some success with the toGlobal function. Although I don't entirely understand what the function does/ what the params should be etc, as the docs are pretty vague. What I would REALLY love is a method on sprites which allows you to get the absolute world x/y positions. World positions independent of sprite rotation and sprite parents. A position that will always be relative to the world, because right now, that's pretty difficult to get manually. Sprite position could be just like the pointer: there are x/y and world x/y; only the x/y are relative to the parent (not the camera, like with pointers) and the world x/y are always relative to the world. Then getting the angle between pointer could be easily accomplished with Phaser.Math.angleBetween. I hope Richard reads this :). |
I don't get your comment. What about http://phaser.io/docs/2.4.4/Phaser.Sprite.html#world ? Sprites do have a world.x/y property! :) |
Holy crap. I thought that was a reference to the game.world. I had no idea such a property existed ... On the one hand, I feel pretty stupid. On the other, my life just got a whole lot easier! |
Bear in mind that that transform only gets updated when the render pass happens (through updateTransform) so it will not reflect any movements you have applied in the current frame. Date: Tue, 3 May 2016 15:57:07 -0700 Holy crap. I thought that was a reference to the game.world. I had no idea such a property existed ... On the one hand, I feel pretty stupid. On the other, my life just got a whole lot easier! — |
Erm, also how about |
…functions: `distanceBetween`, `distanceToXY`, `distanceToPointer`, `angleBetween`, `angleToXY` and `angleToPointer`. The argument (which is false by default), when enabled will calculate the angles or distances based on the Game Objects `world` property, instead of its `x` and `y` properties. This allows it to work for objects that are placed in offset Groups, or are children of other display objects (thanks @Skeptron for the thread #2463)
Thanks for submitting this issue. We have fixed this, and the fix has been pushed to the |
* upstream/master: (990 commits) Phaser 2.4.8 release. Update Documentation in Game.js Sprites that had a tint on them, that then had their frame changed via either `Sprite.frame` or `Sprite.frameName` wouldn't re-tint the new frame, and would become stuck on the old frame in Canvas mode (thaks @spayton phaserjs#2453) Sounds played using the Audio tag, set to loop, would get caught in an endless pause-play loop cycle (thanks @rroylance phaserjs#2473) Position in Body.reset phaserjs#2470 Sounds played using the Audio tag, that were paused and then resumed again (either directly in code, or via a game pause event) would not resume from the point at which they paused (thanks @rroylance phaserjs#2473) If you set Game.renderType to `Phaser.HEADLESS` it will no longer render the output to the canvas. The canvas is still created (although not added to the DOM), as it's required internally, but no rendering now takes place on it (thanks @ForgeableSum phaserjs#2464) Arcade Physics Body has a new property `worldBounce`. This controls the elasticity of the Body specifically when colliding with the World bounds. By default this property is `null`, in which case Body.bounce is used instead. Set this property to a Phaser.Point object in order to enable a World bounds specific bounce value (thanks @VitaZheltyakov phaserjs#2465) Fixed a bug in Arcade Physics Body.preUpdate which would incorrectly apply the position of an offset Body (one which has had Body.setSize used on it) when combined with a Sprite with a non-zero anchor (thanks @SBCGames phaserjs#2470) Arcade Physics has had a new `world` argument added to the following functions: `distanceBetween`, `distanceToXY`, `distanceToPointer`, `angleBetween`, `angleToXY` and `angleToPointer`. The argument (which is false by default), when enabled will calculate the angles or distances based on the Game Objects `world` property, instead of its `x` and `y` properties. This allows it to work for objects that are placed in offset Groups, or are children of other display objects (thanks @Skeptron for the thread phaserjs#2463) TS defs fix phaserjs#2475 Text.setStyle has a new argument `update` which will optionally automatically call `updateText` after setting the new style (thanks @staff0rd phaserjs#2478) fix generateTexture return type BitmapData.copy, and by extension any method that uses it, including BitmapData.draw, drawGroup and drawFull, now all support drawing RenderTexture objects. These can either be passed directly, or be the textures of Sprites, such as from a call to generateTexture. Docs update. Removed, this has gone to its own branch. BitmapData.drawGroupProxy is now capable of iterating through Sprites that have children, and also now uses the world positions for drawing instead. Swap to use worldScale instead of worldTransform. Revert worldScale setter. Typo fix. ...
As suggested here : http://www.html5gamedevs.com/topic/21698-code-improvement-suggestion-for-anglebetween-method/
I've come across some kind of a bug (maybe intended) and I'd like to suggest a fix. In the arcade engine, the angleBetween() method uses the x / y coordinates of the targeted sprites, and I think it should use the world.x / world.y coordinates instead. In my use-case, I had a character with a child sprite, its gun, that I wanted to point to the player. Because the gun was a child sprite, the angle was not correct and the gun wouldn't target the player.
What do you guys think? Are there use cases where it should be x / y instead of world.x / world.y? Maybe I should have used another method like angleToXY(), but I still kind of feel like angleBetween() should be fixed.
Hope it's helpful!
The text was updated successfully, but these errors were encountered: