substandardgaussian

Members
  • Content Count

    45
  • Joined

  • Last visited

About substandardgaussian

  • Rank
    Advanced Member
  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 the tween manager's tween list looking for mySprite as the target, but if you want to keep it correct you'd also need to check every single property of mySprite too, or make sure you always make tweens directly on sprites and not on any properties of a sprite. It's generally easier to keep a reference than it is to dig one up at any given time.
  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 can be a very complicated procedure, so there may be other issues for BadBadGnom, but in diegoalmesp's case I'd start with that and see if the issue is resolved.
  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 should make it work.
  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 expensive since it's so general. I wouldn't rule out Ninja entirely to be honest, it's built for speed. AABB vs. AABB collisions will be present in Phaser 2.4, so of the "basic" collision types it would only really be missing AABB vs. Circle collisions. If your circles will mostly impact tiles or you can get by checking for overlap instead of a proper collision (eg. for bullets), maybe Ninja would be right for you. Or, heck, maybe implementing AABB vs. Circle collisions in Ninja will prove to be faster and better for your application than trying to squeeze more performance out of P2.
  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 performance issues. I'd consider using one of the physics systems in Phaser to help you out with collisions.
  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 groups so the bodies know what they should have contacts with. The end result is basically the same (you can probably find some cases where they aren't), though the actual code ends up being a little different. You'll need to set a callback that is called when, for example, "onBeginContact" is triggered. You can look at the Phaser.Signal documentation to see how to use it. I think it's done this way because sensors, being non-interactive, would end up triggering collision callbacks every single frame, so instead they only trigger the signals when a contact begins and ends. You can set up whatever you need when those signals get sent.
  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.