• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by lewster32

  1. There have been some recent PRs to the (now rarely maintained) Github project which may fix this. Unfortunately I haven't created a distributable with these fixes in, but they're there if you want to clone and build, or apply the patches manually.
  2. My suspicion is that the scope is being screwed up by Map.createTiles being a 'static' method. game.add.isoSprite expects 'this' to be the Phaser instance. You're likely to have the same problem trying to do game.add.sprite or any of the other game.add methods as they all pass 'this.game' to the constructor of the object they're instantiating. To fix this you need to make sure whatever context Map.createTiles is called in is passed the Phaser instance as 'this'. Try this maybe: var tile = game.add.isoSprite.call(game, xx, yy, 0, 'basic_ground', 0, isoGroup); Though structuring your project to better handle being in the correct context from the beginning would be preferable. It's very tricky stuff in JavaScript though!
  3. I've spent the last week or so putting together a fairly comprehensive plug-in for Phaser in the form of an isometric (axonometric and dimetric to be precise) renderer for Phaser. Not wanting to stop there, I decided to go the whole hog and port over Phaser.Physics.Arcade to the new renderer by adding in an extra dimension. You can get the plug-in here: http://rotates.org/phaser/iso/ - the page also contains a working example so feel free to view the source to get a feel for how it works. I'll be creating several more examples in the coming days and weeks, as well as improving the plug-in, fixing bugs and so on. As of yet, I am undecided as to whether to embark on trying to create an isometric equivalent to TileMap (with Tiled importer) but if there's enough interest I may see what I can do. Enjoy, and I'm looking forward to seeing what you do with it!
  4. Bear in mind the above will only delay when the camera starts following, once it's started there will no longer be a delay. If you want the camera to always be 1 second behind the sprite, you'll need to do something slightly different. A simple way to delay the camera behind a target is to use a smoothed camera follow routine such as this: https://jsfiddle.net/lewster32/e6cfnxbo/ To actually force a delay of 1 second (or an arbitrary length of time) is more tricky, not to mention would be quite jarring and unusual for the player. I can't think of a simple way to implement this - I don't think a timer would be the right way to go about it though.
  5. It sounds like it may be a combination of that and the fact you're moving the objects via their parent group. Phaser works out where a collision is taking place on an object and (if necessary and required) how then to separate them via the velocity of at least one of the objects. If you're moving objects as a child of a group, then they're not really 'moving' as far as Phaser can tell, they're simply being visually translated.
  6. The plug-in has nothing like this out of the box, so you'd have to write some routine to do this. I'm pretty sure if you use the .isoBounds or .body Cube properties (bottom, top, backX, backY, frontX and frontY) to compare the positions/sizes of items you should be able to make something workable. I think the naive approach of checking if the sprite overlaps the other doesn't adequately solve the problem, because there are situations where the rectangular sprites' transparent areas are overlapping, which is a false positive. If this is good enough for you however, you should be able to just use the same method as in 'overlap without physics', as IsoSprites extend normal Phaser Sprites. function checkOverlap(isoSpriteA, isoSpriteB) { var boundsA = isoSpriteA.getBounds(); var boundsB = isoSpriteB.getBounds(); return Phaser.Rectangle.intersects(boundsA, boundsB); }
  7. You can't create a single tree sprite if you want some parts of it to occlude and others to be occluded, you have to split the sprite into the parts which are above the player and the parts which aren't, and render the parts which are above the player on another layer which is always rendered on top of the player.
  8. Checking for and setting an arbitrary property on one or both of the colliding sprites ought to do it. Something like this: https://phaser.io/sandbox/edit/CyBbKymD (check the update tab for the overlapHandler method which does the magic). Note that hasOverlapped isn't a Phaser property, just a flag I'm manually creating on the overlapping sprites.
  9. To be fair, the hit from advanced timing isn't that bad looking at the code. If you need to keep track of the fps I'd maybe suggest you do it via a DOM element on the page?
  10. The debug overlays are expensive, especially when using WebGL, as they're not optimised (as is typically the case when enabling any kind of debugging functionality). Advanced timing is also reasonably costly (hence why it's disabled by default).
  11. If I understand you correctly, this is pretty much what I did in the homepage example: http://udof.org/phaser/iso/ (see the source here).
  12. These are 'proper' isometric ratio tiles, so you need to add this to your preload state, as by default the projection angle is for pixel art isometric ratio tiles: game.iso.projectionAngle = Phaser.Plugin.Isometric.ISOMETRIC; All you then need to do is change the spacing when you generate your tiles - 149 seems to work well: // create the floor tiles var floorTile; for (var xt = 0; xt <= 1024; xt += 149) { for (var yt = 0; yt <= 1024; yt += 149) { /* it should be a random with diffrent tiles */ floorTile = game.add.isoSprite(xt, yt, 0, 'tile', 0, floorGroup); floorTile.anchor.set(0.5); } }
  13. More specifically, Sprites need the game object (which is usually 'this' inside a state) in order to initialise most of their subsystems. This means all of your constructors need an additional parameter of 'game', and your instantiation statements should then be something like: var B = new Being(game,300,300,'player'); ... or... var B = new Being(this,300,300,'player'); And when extending Being, make sure that the game reference is being passed also.
  14. Converting 0 - 360 to -180 - 180 is just a matter of subtracting 180 from the value. Handily, as @samme mentions, wrapAngle can do this for you, and also if you pass true as the second parameter, you can put radians in there too.
  15. The addCallbacks method is just a helper for setting onDownCallback, onUpCallback and onPressCallback. See the documentation for more details: http://phaser.io/docs/2.6.2/Phaser.Keyboard.html
  16. This is really the essence of it. I'd like to see the tests you do, as it does seem to make sense that throwing around a gigantic image is going to be more difficult for a GPU than a smaller one, but I'm often surprised by what actually turns out to work well in these kinds of cases.
  17. It's unfortunately entirely device dependent. Generally speaking, GPUs perform better when they have everything they need in one place, and so one large texture atlas is many times better than several smaller ones. What you're usually interested in is the amount of 'draw calls' a GPU is doing per frame. You can debug this easily, and it's a good metric to use and try to reduce. Simplifying somewhat, but every distinct texture used typically constitutes a draw call, so having all of your textures crammed into one texture atlas means that all of the sprites drawn on screen (no matter how many) will theoretically use just one draw call. In practice, tinting, alpha and other things may raise that number but generally speaking you can do a massive amount of optimisation just by reducing draw calls. I did this on a project a while back and the results were pretty astonishing: http://www.rotates.org/2012/11/11/optimisation/ The answer to your question therefore is 'as big as the max texture size for your intended audience's devices', as when all things are considered, even if in a test it seems that 2k outperforms 4k, it may be that in the real world a 4k atlas will reduce your draw calls and give you more fps to play with elsewhere.
  18. The deciding factor is in whether you use AABB or not. AABB (which is what Phaser Arcade and by extension the isometric plug-in uses) cannot represent physics bodies off-axis; they are by definition axis-aligned. You could extend this with circles, spheres and (though slightly harder if using Z axis collision) upright cylinders or capsules - as Phaser has done with the circle bodies - pretty easily, as they are able to function in an aligned environment, having no intrinsic alignment themselves. It'd be impractical to extend this to arbitrary shapes however, as at that point you're basically creating a non-aligned physics system, with all of the extra complexity that brings. I imagine Diablo 2 will have very likely used an AABB + circles collision system (AABB for most map geometry like walls etc, circles for mobs and smaller objects with indistinct 'faces') which would be very fast and do all of the jobs that needed to be done in that game.
  19. Unfortunately I don't think you can feasibly combine standard rectangular physics with the isometric physics; they simply work on different axes. To do this kind of collision detection and separation requires a major re-think of the physics involved.
  20. I'd have to agree with Milton - the isometric plug-in I wrote is a good starting point, but iso is a style where often you need very specific functionality and optimisations. If you're deeply committed to creating a highly optimised isometric game in Phaser, I'd probably look at the many tutorials online; the fundamentals are pretty simple.
  21. Sorry, but this is not possible with AABB physics bodies - they must remain aligned to the isometric axes.
  22. body.immovable = true is the correct one to use and seems to work fine for me, though I think there may be a raft of issues related to incorrect separation on the z axis that I currently don't have time to fix. I may be able to look at it this week and put out a new bugfix release... fingers crossed!
  23. The animation names will be in the .json file associated with the atlas. Generally speaking, if you've generated the atlas yourself you will know the animation names available.
  24. You're better off downloading the files and running them on a local webserver such as xampp or one of the many much more lightweight recent ones than trying to wrestle with the cross-domain, mixed secure content stuff that comes with trying to get this to work in jsfiddle.