Jump to content

substandardgaussian

Members
  • Content Count

    45
  • Joined

  • Last visited

Reputation Activity

  1. Like
    substandardgaussian got a reaction from BrunoHautenfaust in How to read the Documentation   
    In the Phaser documentation, there are only two kinds of things listed: methods and properties. Properties are just variables and are accessed directly by name. The methods may be invoked with parentheses, with parameters where it applies.
     
    If you're having trouble with the "via" column, that refers to the objects pre-defined by Phaser that you can access from a state. When in doubt, they're all accessible from a reference to "game", which is nearly always passed to every object Phaser creates.
     
    So this.game.input.keyboard.lastChar; should work,assuming that "this" has a reference to "game". Can you give an example where the code fails? Which part fails?
  2. Like
    substandardgaussian got a reaction from diegoalmesp in Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined   
    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. Like
    substandardgaussian got a reaction from Tilde in p2 collision WITHOUT physics   
    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).
  4. Like
    substandardgaussian got a reaction from Tilde in p2 collision WITHOUT physics   
    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.
  5. Like
    substandardgaussian got a reaction from J4G in Physics in Phaser handling large worlds   
    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.
  6. Like
    substandardgaussian got a reaction from Tilde in Extended sprites don't appear if added as children?   
    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.
  7. Like
    substandardgaussian got a reaction from Nikow in 'Speed' of spriteSheet Animations ?   
    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.pedale You 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.
  8. Like
    substandardgaussian got a reaction from Raiper34 in Tween understanding   
    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.
  9. Like
    substandardgaussian got a reaction from flowabuse in Is physics.p2.enableBody the same as physics.p2.enable?   
    Just look at the source, there's a link to the related property/function for all of the documentation in Phaser.
     
    p2.enable calls p2.enableBody. p2.enable is basically a wrapper around p2.enableBody that handles recursion/enabling multiple bodies in groups/arrays.
     
    What's actually happening is that you have an odd construction by having the graphics object be a child of the sprite. It's trying to enable a body on the graphics object and failing. That's why enableBody works: it doesn't try to recursively apply "enable" on the children of this. p2.enable does do that.
     
    It should be fine in theory, because the graphics object inherits from PIXI.DisplayObjectContainer, and the "children" of a DisplayObjectContainer is an array of DisplayObjectContainers, but P2 in particular seems to expect objects to have an anchor point, which is not a native property of a DisplayObjectContainer.
     
    You can use
    game.physics.p2.enable(yourObject, debug, false); to tell P2 not to recursively make bodies on yourObject's children.
     
    You could just enableBody, but for consistency you should probably use the provided wrapper that interacts appropriately with groups/arrays.
     
    The fact that P2 assumes something wrong about an otherwise perfectly valid object should probably be considered a bug. There's no guarantee that the child nodes of a DisplayObjectContainer have an anchor point.
  10. Like
    substandardgaussian got a reaction from Raiper34 in Some OOP technique in Phaser   
    You can use the "new" keyword like you would in any other OOP language.
     
    You first have to construct a prototype object with a constructor function that JavaScript recognizes as a constructor (otherwise you will get a runtime error using "new"). Red Spark's post shows you how.
     
    1. Define your constructor function, giving it the name of the object class you want to create.
    2. Give your constructor function a prototype object. This should be the superclass of the object you want to make (the class your class inherits from). Use Object.prototype if you don't want to inherit from anything.
    3. Set the special variable constructor in your prototype object to your constructor function from #1. This tells the "new" keyword what to use to set up your new object.
     
    This example is completely Phaser-independent. Doing it in Phaser is identical to doing it in JavaScript (though of course the content of your constructor will interact with elements of Phaser).
     SampleObject  = function(x,y) {      this.x = x;      this.y = y;      return this;}; //1 SampleObject.prototype = Object.create(Object.prototype); //2SampleObject.prototype.constructor = SampleObject; //3 var instance1 = new SampleObject(0,0);var instance2 = new SampleObject(8,55);
×
×
  • Create New...