boolean

Members
  • Content Count

    21
  • Joined

  • Last visited

About boolean

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

676 profile views
  1. You should be able to just join .onComplete to the tween without setting up a new variable. I think the issue is that .onComplete.add is losing access to your shipWeapons property. Your code should look like: game.add.tween(shipWeapons[y][x]).to({ alpha: 0 }, 200).onComplete.add(function (shipWeapon) { //shipWeapon is the shipWeapons[y][x] property you gave your tween. shipWeapons is no longer in scope so you can't access it directly. shipWeapon.loadTexture(this.reference); game.add.tween(shipWeapon).to({alpha: 1}, 200); //Is this supposed to be 1? }, this);I'm not 100% sure why the tween loses access to the outer variables, but I think it's because the function which has your shipWeapons property isn't the one actually calling the onComplete, the tween is, so it loses access to any variables not directly passed to the tween. Maybe someone with more JS experience can fill in here.
  2. From what I can tell P2 already supports it
  3. After some more experimentation, I think I know what is making this confusing. Setting an anchor point moves the position of the texture that is assigned to a sprite object, but it does not change the position of the sprite object itself (as seen in this example). However, the physics body DOES move with the texture (not the sprite) when the anchor point is changed. Even more confusingly, game.debug.spriteBounds shows the box of the texture position (via the anchor point), not the sprite game object. This also means that because the sprite is not moving, the .world position also stays the same resulting in my original problem - the texture and the body being in two different places.
  4. Aha! I figured out what is causing it...I'm just not sure why its happening. It's when I set the anchor point to (0.5, 0.5). For some reason that's moving the sprite coordinates way off center. If you to this example page and paste in the following code, you'll see the same effect. I'm sure I'm missing something obvious here... var game = new Phaser.Game(800, 600, Phaser.CANVAS, 'phaser-example', { preload: preload, create: create, update: update, render: render });function preload() { game.load.spritesheet('gameboy', 'assets/sprites/gameboy_seize_color_40x60.png', 40, 60);}var sprite;function create() { game.physics.startSystem(Phaser.Physics.ARCADE); game.stage.backgroundColor = '#124184'; sprite = game.add.sprite(300, 100, 'gameboy', 3); game.physics.arcade.enable(sprite); sprite.body.immovable = true; sprite.anchor.setTo(0.5, 0.5); //this is being set to the bottom right corner instead of middle}function update() {}function render() { game.debug.body(sprite); //BODY - RED game.debug.pixel(sprite.body.x, sprite.body.y, 'red', 10); game.debug.pixel(sprite.body.x + sprite.width, sprite.body.y, 'red', 10); game.debug.pixel(sprite.body.x, sprite.body.y + sprite.height, 'red', 10); game.debug.pixel(sprite.body.x + sprite.width, sprite.body.y + sprite.height, 'red', 10); //WORLD - GREEN game.debug.pixel(sprite.world.x, sprite.world.y, 'green', 10); game.debug.pixel(sprite.world.x + sprite.width, sprite.world.y, 'green', 10); game.debug.pixel(sprite.world.x, sprite.world.y + sprite.height, 'green', 10); game.debug.pixel(sprite.world.x + sprite.width, sprite.world.y + sprite.height, 'green', 10); //SPRITE - BLUE game.debug.pixel(sprite.x, sprite.y, 'blue', 10); game.debug.pixel(sprite.x + sprite.width, sprite.y, 'blue', 10); game.debug.pixel(sprite.x, sprite.y + sprite.height, 'blue', 10); game.debug.pixel(sprite.x + sprite.width, sprite.y + sprite.height, 'blue', 10);}
  5. Here are the links I was thinking of that discusses this issue. They talk a lot about raycasting (and the first link is about Unity), but the math and concepts are all the same: http://deranged-hermit.blogspot.ca/2014/02/2d-physics-in-unity-with-raycasts-slopes.html, http://www.gamasutra.com/blogs/YoannPignole/20131010/202080/The_hobbyist_coder_1_2D_platformer_controller.php?print=1 One thing I messed up in my original post (serves me right making sleep deprived posts!) was when I mentioned "if a wall is detected the player input in that direction is turned off", that's actually a solution for when you hit solid 90' walls (as valueerror pointed out). Some physics engines have an issue where if you hit a wall and your velocity.x is > 0, the player just ends up sticking to the wall. In your case what you want to do (which the article discusses) is to basically fire out a ray from the player, get the angle of the slope and then multiply the players velocity by that. Since raycasting isn't as easy in Phaser as Unity, you could build yourself a set of 3-4 sloped floors and then hardcode the angles into them. Then when the player collides with it you have a factor you can multiply the velocity by. There's still some edge cases to take care of but I think that's probably the easiest way.
  6. Dang, I have to go to sleep but I'll just quickly mention - this is a common problem in all the physics based platformers I've used. Boot up the Unity platformer demo, put a wall at an angle and you'll notice the same problem. The cause is that the physics engine doesn't understand walls, it's just applying the velocity.x as hard as it can against what it thinks is the floor. That small angle is enough to keep your velocity.x just slightly above 0, so when you hit the wall you just very slowly inch your way up it. When I was using Unity the common fix for this was to raycast a few pixels in front of the player - if a wall is detected the player input in that direction is turned off. Once the player is back on the ground and not facing the wall, the input in that direction is turned back on. I need to sleep but tomorrow I'll try and dig up some old blog posts on this if I have time. Some extra stuff before I go to sleep: If you want to see a funny side effect of physics engines not understanding the difference between floors and walls, check out Counterstrike wall surfing: https://www.youtube.com/watch?v=2_NQradnzFY Look into Phasers Ninja physics - it's designed to handle angled floors.
  7. It's loading ok for me. What version of Chrome are you using? Maybe try clearing your cache?
  8. No cropping, padding or offsets. I tried your debug code and the body and spriteBounds appear to be in the same spot, which is interesting. Maybe it's how I'm using the numbers. Originally I was trying to do a Phaser.Line to the four corners of my sprite so I could do an Phaser.Line.intersects check. When I noticed my laser was hitting the target while wildly off target I tried doing a debug.pixel to see where it thought the 4 corners were. Here's what I get:
  9. You could probably do something like this: http://phaser.io/examples/v2/display/graphics
  10. Hi there Is there a reason why the .body.x/y property on my sprite would be different to sprite.x/y? I've been trying to figure out all afternoon why I can't see to get the correct location, and it appears the sprite.x location is about a full width away from the actual sprite (the body has the correct coordinates). I've scaled the image up to 4, set the anchor to 0.5 and added it to a group. Would any of those have this effect? Is there any reason the body would be in a different location to the sprite? I can't imagine why the two wouldn't always be the same.
  11. Awesome, glad you got it sorted
  12. Hi there I made a blank project and noticed when I added a tile layer I get the following javascript error:
  13. It's a bit hard to tell without seeing any code, but here's my guess. When you add your satellite objects to the parent planet, their position becomes relative to the parent. So if your planet is in the very center of the screen (eg. x:200,y:200) and your satellite is in the very top left of the screen (eg. x:0,y:0), when you call addChild(satellite) on your parent planet your satellite will jump to the middle of the screen because it's position is now x:0,y:0 relative to its parent (which is in the middle of the screen). The tricky part comes when you want to keep your old position, but still take into account its relative positioning. In this case you originally had the satellite at a world position of x:0 and y:0, so when you child it to the planet their sprite.x will be 0, but their actual sprite.world.x will be 200. Unfortunately I'm not 100% sure how to get the sprite back to its old relative position, but if you know the distance to set the relative positions you can just do that (eg. you know all the satellites should be at -100px from the center of the parent because the planet is 70 pixels large).
  14. @valueerror: Thanks, yep that's correct - I was more curious about the 'why' rather than the 'how'. If there is a reason that you need to double-bind collisions, it would be good to know what case that solves. I like your pseudo code and it works a lot closer to how the collisions are setup in Arcade physics. I wonder what the reason for that not already existing is. Curious!
  15. Ah nuts, you can't set that in code? Some other frameworks I've used have built in support for padding (plus padding types). Well I'll just pad it manually in the file for now. I've not tried writing any extensions for phaser yet, but if I can figure out where it stores the pixel data it shouldn't be too hard to jam some spacing in there on the fly. Cheers!