substandardgaussian

Members
  • Content Count

    45
  • 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 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.
  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 body.shapes array and sets all the sensors that way. I don't know why fixtureData is a string in the documentation, it's accessed like a normal object in the code. fixtureData contains a lot of information and using it is mostly internal, you probably don't need to deal with it unless you're doing something very special. Basically, everything is exactly the same except you need to take a moment to set the shape's sensor property. That's it: the shapes won't cause physical collisions anymore, but they will still trigger collision callbacks so you can detect touching them.
  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.shapeOffsets[0][0] += len[0] - this.data.shapes[0].vertices[ref][0]; this.data.shapeOffsets[0][1] += len[1] - this.data.shapes[0].vertices[ref][1]; }This only works given that we're looking to lock the bottom-right vertex for a body that contains only one horizontal line (or we might find the right side of the other horizontal line first): regular rectangles are handled separately. There is a different case for each different "type" of tile constructed. In this case, moving the body's position has the same effect as moving the shape's offset. I think this could be generalized to create a P2.Body.anchor property that moves the point around which all body operations are performed. Moving the vertices explicitly instead of just changing the offsets causes P2 to freak out pretty hilariously with its collision detection and responses.
  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 your custom properties. You can write the render in manually if you want, but it's probably more advisable to make sure the object exists somewhere in the chain of child nodes that link up to game.world.
  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 glued to a particular vertex of the tile image, and with arbitrary slices/angles, the polygon I end up with can have completely arbitrary offsets from where it's supposed to be. I don't want the center to be in a known position, I want a vertex to be in a known position. I've tried doing a translation by the centroid of the polygon, but it doesn't line up consistently. Does anyone know how I can tackle this problem? All operations on p2 bodies seem to be relative to the center of mass.
  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, though, and you'll almost certainly get the wrong result, though they may be close. I'd probably override p2.update() to call world.step with the other parameter if necessary. I don't think there's a way to do it strictly using the public-facing API.
  24. Incidentally, the latest is 2.3.0: http://phaser.io/docs/2.3.0/Phaser.BitmapText.html