Oscar Abraham

You can also pixelate anything with a proper webgl filter. Or you can draw to a smaller canvas texture, disable smoothing and make it larger.

I'm glad it was resolved :-). What a weird profiler behavior, it seems to me it's a bug. Maybe you should post an issue on chrome.

You are using the soundManager in a wrong way. I don't know if it will solve all the problems, but I hope it will. game.sound is a reference to the soundManager. When you call its play method, it adds a new sound object and starts playing it; so each time you play a sound you are actually adding a new sound without deleting the previous one. That method actually returns a sound object, so you could use it to create all the sounds that you need to play right away and keep a reference to them so you can play them again: var moo1 = game.sound.play('moo1');//and when you want to play it again.moo1.play();Personally, I think it is a bad practice; most of the sounds you usually need shouldn't play right away. So I suggest using the gameObjectFactory to add any sound or any other instance of an asset you need; it will be much less confusing. For example, for audio you could do:var moo1 = game.add.audio('moo1'); //or "game.add.sound('moo1');", it's exactly the same.moo1.play();Phaser has too many ways of doing the same things and some ways are a lot better than others. It is one of it's main flaws in my opinion, but i believe it will be fixed in Phaser 3. In the mean time, one has to be careful to use it the best way. I hope it helps.

You could actually use any MVC library you want and Phaser together. If you are only using Phaser, you can also do it; but prepare your self to do some good amound of coding to fill in parts that phaser does not have, because Phaser is not that good at being anything else than a game engine. Maybe your life would be easier if you combine something like bootstrap or backbone or your favorite MVsomething library with Pixi. It sounds that most of what you'd be using Phaser for is already supported by Pixi.

It is not a bad principle. If the sensor property is false, it is just a normal shape that collides normally. It is true that sensor shapes don't collide, but they still fire on begin contact event when they overlap with another body and are still managed by the physics engine. The contact functions can fire from both of the shapes that make contact. If A makes contact with B, the event might fire from A making contact with B and from B making contact with A; it doesn't matter if A or B or both or none are sensors. If you use sensors in this way, not only would it be waisting resources from the machine because it is watching shapes that don't need to be watched, but also you would have to check each time inside the contact functions if the shapes colliding are sensors or not, which seems like unnecessary work. Also, like I said before, you might want to have shapes that are always sensors, no matter what frame it is; for example a move where a character puts a sword through another character might require the sword to detect overlaping on the other player, but also to not push the other player away. Something along that idea but with a subtle difference that might work better, is my third idea: when a shape is not needed (no matter if it is or it isn't a sensor), instead of making it a sensor, you add it to a collision group that doesn't collide with anything, when a shape is needed you add it to a collision group that makes contact with the things that need to be contacted. All, shapes are still managed by the engine, but at least they are not checked for overlapping with anyother shape; also, you don't have to manage the contact functions so much and you can use sensors for what they were meant to be used: to check if something overlaps with something.

PD. 3. You could have all the shapes from all the frames active at the same time. And only remove from collision groups the shapes that you are not using and add the shapes that your are using. You would still have to manage a separate array of shapes or implement another way of knowing wich shapes work in every frame. I belive this would require roughly the same amount of code than the second way and that it would be moderately more expensive, because the p2 library still has to manage the shapes for all frames at the same time, even if most of them don't collide, but it might be a lot easier to understand because you don't need to manage the bridge between phaser and the p2 library as much.

Yes. I guess it can be difficult to get because it is not in the phaser documentation. To use sensors, you have to directly access the p2 physics body. The p2 physics in Phaser is just a bridge between the library and the game engine, so for example, in order to access the real p2 body of a body, you have to acces its data property: body.data;The real p2 body (you can check its reference here: http://schteppe.github.io/p2.js/docs/classes/Body.html) has a shapes property, which is an array of shapes that belong to that body. Then, you can access each shape; so, for example, this gives you the first shape of a body: body.data.shapes[0];From there you can set it as sensor, a sensor will check if it overlaps other bodies' shapes, but wont generate collision data nor calculate forces, so it is easier on the processor. Also, it allows you to check if something overlaps with something without having to do really weird tricks. A note: if you are using the collision data that onBeginContact and onEndContact give to you, you most check if one of the shapes if a sensor, otherwise, it will throw an error beacause that collision data doesn't exist. To set it as sensor, you do body.data.shapes[0].sensor=true;Accessing the data propertie of a body is useful because some really cool features of p2 physics are not directly implemented in phaser. Also, you can set shape sizes, velocities, forces, position etc. in meters; that can make easier to manage different resolutions of your game, since the numbers you set in meters will adapt to the scale you set for the p2 physics implementation in phaser without having to preprocess them. Disabling the shapes is another matter; a huge matter. I can think of two ways right now: 1. You could do as you suggested, since you in phaser you cannot have multiple bodies for one sprite, you would have create a different empty game object for each significant frame you have. Then, add the corresponding shapes to each object. You would have to create a different game object, with the animated sprite and without physics, that follows the active game object with physics. Each frame you remove the past frame's active physics body from the world and add the current frame's active physics body. You would have to manage a more complex contact management, since you'll have a different set of collision events for each body. You would also have to integrate the forces you and the p2 library add to the active body with the rest of the bodies, because the bodies are different between them; the forces and acceleration applied to the active body, do not apply to the rest of them. You'd have to copy the velocity, rotation and position of the active body to the rest before removing it and, depending on how much you use the physics, you would have to be smart when applying accelerations. Each thing you do to the character, you would have to do it to all of its physics bodies. I believe if your game is relatively simple, this could be the easier method to implement, but each layer of complexity you add makes the code harder because the body sincronization problem (and if it is that simple of a game, why not then use just use arcade physics and compare pixel masks for collisions, like old games). Also, you would have to profile to be shure, but I think this would be a much more expensive way; there would be a lot of objects and a lot more process on each update loop. 2. You can store all the shapes you need in an array or an object; and then each different frame you remove the shapes you don't need and add the ones you need (depending on your game and how precise it is, you may need to remove all the shapes each new frame or you may keep a shape that roughly represents the main body in all frames and little sensor shapes that represent atacks). This method requieres more code on the object creation part, but then it is much more easier to manage. You only have one body atached to the sprite you are using. All tweens and all weird physic stuff you do, becames as simple as what you would do with any other body. Also, I believe it would require a lot of less resources from the browser. To use this method, you would have to do a trick to store the shapes into an array separated from the body. You could import the shapes as you would normally do, copy the shapes array from the data property of the phaser body to an array, and then call clearShapes on the body so that the body is clean and you have a copy of the shapes stored for later use. Note that you would also have to copy the shapeOffsets array of the data property too, because Phaser, in order to do some weird thing with the center of mass of the shapes that I'll explain later, has to apply an offset to the shape in order for it to fit the sprite. So, when readding a shape, you would also have to apply its offset. Or you could implement your own shape creator, you could look at the source of the loadPolygon method, it's really easy, you can pretty much copy it and instead of adding the shape to the body, add the shape to your array. I believe you could strip it even more; it does a lot of work to center to center the shape around its center of mass, and then it compensates by adding an offset to the position of the shape when it adds it to the p2 body. I don't know why it does that, there is probably a reason, but at first stance it doesn't seem like a really good idea to me; the center of mass is normally important for realistic physics; and centering the shape around it just negates it. I imagine that a fighting game doesn't care for the center of mass of a shape, since you would probably constrain the rotation anyway, but stripping the weird center of mass of the code would allow you to avoid having to manage also a shapeOffsets array and it would simplify your code. After implementing your shape manager array, (wich could be an array of arrays of shapes, so that you have your shapes organized by frame, or whatever other organization method you want) you would need to update the shapes each frame; do this directly in the phaser body, so that the debug render updates too. If your shapes are completely different each frame, then use first body.clearShapes. If not, you can use remove each shape you need to remove. Then you just have to use body.addShape to add the shapes you need. If you didn't deal with the center of mass offset issue, then, when passing the offset to the addshape method, you have to use the mpxi method inside body.world to convert from p2 units to phaser units. I tell you all this, because I haven't tried each option, I've never really had to. And I don't have much free time right now. And I'm honestly too lazy to check them, and it seems easier to just write my stream of thought now, but none of them seem to complicated to try. And all of them would work, its a matter of what works better for you, so I give you the information I think you need to decide. Though, I sometimes write in a very confusing way without realizing, so I hope it's not that confusing. And if it is, well, here I am.

I don't know why the entire spritesheet showed. I'd have to see some code. I imagine you are using p2 physics, but even if you are using arcade, I wouldn't recomend creating so many bodies for this. It would be better to simply create one body, add all your shapes to it, and disable them all. Then I would check to see which frame the animator is currently showing and enable only the shapes that are needed for that frame. I imagine you'd have to implement your own paradigm to organize a way to know which shapes go with which frames. I supose you would need multiple shapes for each frame because, even if you are using simple collider shapes, you may need some shapes that are defined as sensors so that, for example, only one foot hurts the other player when a kick is thrown. That way you do not need to manage multiple bodies, which makes the code much more complex and takes a lot more resources from the computer; but at the same time, you do not have to create and add shapes each frame, which is also bad. Is much more faster then. P.D. Also, the more you use sensors instead of full colliders, the easier it will be on the processor.

It would be nice to get direct phaser support for dom elements that could be inside of some kind of main game div and scaled with the whole game. That way it would be easier and sometimes even cheaper to incorporate forms, banners, videos, etc. to a game.

: ) You should do that. I often find that physics written on javascript aren't usually very stable, I supose it is because javascript is kind of heavy. Asm is doing great things on Firefox, though. I hope you do make the contribution to P2.js, it would be really cool. The best javascript written physics library I know is the one that comes with Turbulenz, but Turbulenz is so complicated and I am to lazy that I mostly leave everything related to it alone.

HIya! So many fun games! Here's mine, submited it half an hour before the end. It's the first time I've used shaders with Phaser. Hell it's the first time I've really used Phaser for something other than little experiments. But it was up to the challenge. Thanks to all the people that contribute to the library, it's awesome. It has music from my band in Mexico, Dolphant, they actually helped me with most of the graphics and the sounds. They are such good guys. Anyway. Here it is: http://ludumdare.com/compo/ludum-dare-31/?action=preview&uid=45778 and here is two screenshots:

I'm reading the source code and I'm really happy with what I see on the implementation of physics. At least by what I understand and please correct me if I'm wrong, the physics step runs in the updateLogic method, which runs just enough times to keep with a desired fps, which its kind of like if it had its own clock. Even though before p2 could run with a numerically fixed step, the step method was called the same number of times that the rendering methods; so using a slower p2.frameRate in the same machine would make the game physics movements aparently go faster. It seems now the p2 clock is also properly decoupled which is a lot nicer; I can just use a p2.frameRate that is proportional to the desiredFps to solve my time accuracy problems. It still would be nice if the rendering took into account each sprite's velocity in order to interpolate its position accross multiple render updates between two logic updates, but the overall change in how the update works is very cool and makes precise mechanics much more easier to implement. So thank you again; I'm really glad for Phaser 2.2. -- P.D. Also, I'm probably wrong, I'm still learning about videogame programming and programming in general, so sorry if I'm wrong. I'll say this any way for if it helps somehow: Line 774 of Game.js, which is this.updateRender(this._deltaTime / slowStep);seems to pass to update render what is equivalent to updatesThisFrame, not elapsedTime. I doesn't seem to be used or to affect something, but I thought there's something weird with that and it might help somebody. I know I'm probably wrong, so please forgive me if i'm being a fool.

Congratulations and thanks for that awesome release. One question: ¿do the other physic engines, ninja and p2, also benefit from the fixed step game loop?

Thank you! That's going to make a lot of things easier for me.

It would be nice to have an update method that runs on par with the render loop and an update method that runs on par with the physics loop. And separate loops for the physics engine and the renderer; just like Unity 3D has, for example. That way we could have a fixed timestep for physics, that's much better for it: (read http://gafferongames.com/game-physics/fix-your-timestep/) and a variable render loop that let's the game play as smooth as posible. Having an update method for each loop would let us do stuff that only makes sense to do after the physics engine has advanced one step, and do everything else when the graphics are ready to be drawn again. It would also let us tailor the game loops frequencies better to a game, making physics that do not need to be very accurate be able to run slower on those games, without losing render fps, and the other way around.