Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by substandardgaussian

  1. You could add that kind of functionality yourself if you need it. Tweens are managed by a global tween manager and not by the things they are tweening, since you can tween nearly anything, whether it's aware of tweening or not. If you need a sprite to manage its own tweens, you can extend or modify the Phaser.Sprite class with a makeTween function that's a wrapper around this.game.add.tween, except it also keeps a local reference. If you do that, then you can keep sprite tween management local without affecting the tween manager's ability to tween on anything. An alternative would be to walk
  2. The hasOwnProperty check is the first place where the object you're passing in is dereferenced. This means that you're probably passing a null reference. When you make a call to state.start, the second parameter is whether you want to clear the World display list, which defaults to true. Any objects that are children of game.world (which, in most cases, is all of them) are cleared, so if you need display objects like sprites to persist between states, you need to call start.start("Game", false) to make sure pre-existing things in the game.world aren't erased. Of course, switching states ca
  3. I tend to use physics on everything, so I don't have a lot of experience with this, but I believe tile collision properties are Phaser properties that are independent from physics systems like Arcade. You're not setting bodies on any of the tiles, you're just setting flags that the game engine checks independently of physics. Arcade's body.touching cares about Arcade bodies, so from its point of view your sprite isn't actually touching anything. If you want to use Arcade physics, you should set physics bodies on your tiles instead of using the built-in collision properties in Phaser. That sh
  4. Absolutely. Being a sensor is a property of a single shape, not a whole body. You can create a body and add more than 1 shape to it, so the sensors don't collide with anything but the non-sensor shapes do. But it sounds like you want your body to collide against certain things, but not others. This is actually built into P2's collision groups. Make sure every body you make sets its collision group, and control which groups collide with what by using the collides method. There's a special variable for colliding with the world bounds (body.collideWorldBounds).
  5. What do you mean by "get them out"? createMultiple is useful to generate many sprites with the same spritesheet. If you want different spritesheets you'll need to pass a different key on a different call to createMultiple. If you want to do processing on individual sprites after you've created a bunch, you'll need to walk your group with forEach or iterate or something equivalent.
  6. Put all your people in a group and check for overlap against the group. Arcade will walk the group and test for overlap on all of them separately.
  7. It's really tough to say much about optimizing, since it depends so heavily on your specific implementation details. If you absolutely must have such a large world and you don't want to be destroying sprites (or p2 bodies), have you considered setting the shapes in bodies that are offscreen into sensors? They won't trigger collisions, so if you didn't attach any contact events to them they effectively become immaterial to P2. Are you using impact events? If you are, you can try disabling them and instead use contact events to process collisions. Other than that though, P2 is pretty expensi
  8. If you want to be particular barebones about it and don't want to introduce any other frameworks, you could use a Phaser.Rope object with careful application of particle emitters to create a simple wavy water/splash effect. It won't really behave like water mostly, but for certain things it'll give enough of an illusion.
  9. So you're not using a physics system? If I'm not mistaken, using sprite.overlap vs. a Group might be problematic because the Group's getBounds function is based on the furthest children, so if you have 2 enemies on opposite sides of the screen in the same group, the entire space between them is considered a part of the group's bounds and will cause overlap to return true. You can write a recursive function that walks the children of the children of a group, but be careful. As the documentation says, sprite.overlap is an expensive operation, if you do many checks often it might cause perfor
  10. Phaser.Group.create doesn't work the way you're using it there. It's trying to interpret the object you're passing as an x value. What you probably want to do is set this.shields.classType = BlaadShield And use the appropriate parameters for create to make your shields. Also, you should probably make your shields group with this.game.make rather than this.game.add, since add will automatically add the group to the game world, so when you attach it as a child later Phaser might end up counting it twice for various processes.
  11. You're trying to set the "speed" property for the AnimationManager, not the animation itself. AnimationManager doesn't have a "speed" property, it won't do anything with it. You can access your pedale animation through bike.animations._anims['pedale']or bike.animations._anims.pedaleYou should be able to set the speed there. You can set your frameRate when you call add, if you know the speed you want to play it at in advance.
  12. I actually have the exact same problem. I took a break from dealing with mouse controls for a bit, I guess sloth and prayer didn't find a fix for me! I'll probably be trying to figure out what's wrong here sometime in the next couple of days, but I'd appreciate an answer in the meantime as well. I've found that it doesn't work on both on Firefox and Chrome, even with mouse capture.
  13. Eh, kind of. Every function that sets a callback also generally lets you set a callbackContext (sometimes called listenerContext), which lets you define what the this variable will be when your callback is called. You can use that to construct an object that has all the information you need during the callback. Also, I just wanted to clarify something, because I think I steered you wrong: Sensors will NOT trigger collision callbacks! What they WILL do is trigger contact events which send signals, such as "onBeginContact" and "onEndContact". I believe you still need to set up your collision g
  14. The first thing I noticed on switching to the RC is that my sprites no longer loop their animations. I know the animation is correct because I see the sprites change exactly once (2 frame animation). After that, the console indicates that currentAnimation.loop is true AND that currentFrame.name changes from "0" to "1" and back at the right rate, and the currentAnimation.loopCount increases like it should, but visually, nothing changes after the first loop. All the sprites are stuck in the second frame of their animations forever. Everything about it looks right besides the actual rendering.
  15. You DO want to use physics.startSystem, that's what gets the ball rolling on the physics systems so they work. You'll need to start P2 and use p2.enable on your sprites as normal, because they still need to have bodies. There are actually a few ways to deal with sensors, the easiest is probably to go ahead and add shapes to your body like you normally would, except store the shape (almost all of the shape-adding functions return the shape they added) and just set shape.sensor to true. Or if you just want to make sure entire bodies are sensors, just call a function that iterates over the bo
  16. Figured it out! It is... not fun. var len = [this.world.pxmi(tile.width), this.world.pxmi(tile.height)];//find the anchor axis var ref = null; for (var i = 0; i < this.data.shapes[0].vertices.length; i++) { var axis = this.data.shapes[0].axes[i]; if (axis[0] == 0 && axis[1] == -1) { //normal axis to our line, guaranteed by the constraints on the tile body ref = i; break; } }if (ref != null) { this.data.
  17. It's really hard to tell without seeing all your code, since we can't see what the TILES property is or what it's a child of, but if you want Phaser to render the sprite correctly, it needs to be somewhere Phaser can find it during its rendering operations. Generally, it needs to be a child of game.world, or a child of something that is in the game.world, etc:. If the only place you indicate that the entity exists is in the "gem" property, Phaser doesn't know it should be trying to render that. It will walk down all the nodes from game.world.children (children), but it won't look in any of y
  18. I wanted to give P2 physics a little more support for non-square tiles, so I'm working on a utility that builds bodies for tiles. For my purposes, a tile can be anchored either to the top or bottom (has a full-length edge that is the same length as the edge of the tile), but can be sliced anywhere else with an arbitrary slope. Actually making the body is easy... but trying to place the body in the right spot is proving to be difficult. When you make p2 bodies, everything is based around their center of mass. This is entirely unhelpful, because I need a particular vertex of the body to be glu
  19. Whoops, yeah, it's for shapes rather than whole bodies, sorry for not being specific. It's much more useful that way: you can have a regular rectangular hitbox for an NPC and add, say, a cone shape as a sensor to represent its vision.
  20. A sensor is a physics body that has no collision response, but still triggers collision events. Just as an example, you can set your powerup's body to be a sensor, so you don't have to worry about it knocking anything around, but you can still make it "collide" with the player's ship so it triggers a callback that causes the ship to pick it up. So you still need to make use of P2's tools, like creating collision groups and setting callbacks, it just doesn't do anything other than report on the "collision".
  21. Ninja Physics can do a few other shapes, namely circles and tiles with various slopes, but the tiles aren't really full physics entities, they exist for other entities to collide with. Still, Ninja was developed originally for N, which performed very well for its time and can do a lot.
  22. The .to and .from methods add tween data to the tween, they don't override it. You can do some trickery to remove previous data (set tween.timeline to an empty array before calling to or from), but it looks like tweens in Phaser are meant to be disposable. I don't think their behavior is guaranteed if you mess around with the internals.
  23. Interestingly, the p2.world.step function takes a second parameter that is the "time since last called". P2 then tries to do fixed steps from that time until it gets to now. Unfortunately, p2.update() calls world.step without that second parameter and there's no "mainstream" way to supply that parameter. You can actually set p2's frameRate variable, and it will step the world according to that rate, not the actual rate that the update method is being called (which will still be called at the actual game framerate by the main game loop). Bigger time steps will cause physics artifacts, thoug
  24. Incidentally, the latest is 2.3.0: http://phaser.io/docs/2.3.0/Phaser.BitmapText.html
  • Create New...