rich Posted January 14, 2014 Share Posted January 14, 2014 Hi all, A lot of hard work has gone into 1.1.4, and I'm very nearly ready for release but there are some significant API changes, so I'd really like to get some more people testing it first. If you've got time please checkout the dev branch (I've added compiled js files for you as well) and give the new features a test: Tilemaps These have changed significantly. You no longer need to use load.tileset, you can have multiple layers, multiple tile sets per layer and all kinds of fun new things. I have updated most of the tilemap tests to the new format + the Star Struck game example. Also look at examples/wip/tilemap.js for examples of multi-layer and object stuff. Please test them! Collision should be significantly better now as well. Updated Physics I've updated the way physics works across the board and simplified the collision / overlap systems loads. Also the process callback now works as you'd expect it to - i.e. only if your process callback returns true do the sprites then actually collide! Note: Body.drag has been removed and replaced with Body.friction. Also you can test the new Body.canSleep properties too. Look at examples/wip/physics-motion.js for an example. There are lots of other updates as well, see the readme for details. New Timer class Please give it a go Lots of new examples showing how to use it too. Still to do: 1) Sort out Camera following2) Allow tilemaps to be positioned somewhere other than 0,03) Tile specific collision callbacks4) Release this monster. jerome, BitlasLT, Arlefreak and 1 other 4 Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2014 Share Posted January 14, 2014 started looking at it earlier today. am porting my Nadion library (https://github.com/jcd-as/nadion) and an in-progress game which uses said library. so far, so good. I've noticed the following things - aside from follow modes using the deadzone not working - Emitter has a particleDrag property and still tries to set the body.drag property, which fails. (I have a fix for this - changing it to a particleFriction scalar instead of vector - but I'm having some branch issues with my repo, so I haven't submitted it. trivial change anyway) - my player sprite in the Nadion sample (a side-scroller), which initially starts on. the "ground" starts by falling through the ground tiles every time. after I jump him out he collides with the ground tiles fine. not sure what's causing this - the same sprite occasionally just stops moving in mid-air after a jump (always while falling from the peak of the jump). always happens when I'm not pressing any keys / not changing the sprite's velocity. haven't tracked this down yet either - rather intermittent and hard to debug. - the physics values (gravity, velocity) required for the same behaviour have changed significantly, which makes it hard to port a game's behaviour. c'est la vie, I guess Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 I expect the issue with him stopping mid-air was the 'canSleep' parameter. I disabled that last night (was on by default before) so it should stop doing it now I'd hope. Am looking at ground based collision right now, as I need to stop it 'jittering' when starting on ground / tiles. Thanks for the Emitter catch, will fix Link to comment Share on other sites More sharing options...
XekeDeath Posted January 14, 2014 Share Posted January 14, 2014 Just added the latest dev builds to my personal projects folder at home...I'm not using any of the things you wanted tested out yet though, but I will post any problems I have along the way... I'll definitely take a look at timers, they may prove handy for what I want to do... Link to comment Share on other sites More sharing options...
BunBunBun Posted January 14, 2014 Share Posted January 14, 2014 Tested tilemaps and timers - works fine for me now! Thanks! Link to comment Share on other sites More sharing options...
Pixelguy Posted January 14, 2014 Share Posted January 14, 2014 Not a bug but I don't quite understand the tile loading examples. Why load the tiles like this:game.load.image('tiles', 'assets/maps/cybernoid.png', 16, 16);And add a different file which is an exact copy of "cybernoid.png" ?map.addTilesetImage('CybernoidMap3BG_bank.png', 'tiles'); However in the multilayer demo (examples/wip/tilemap.js) you are doing it the way as I would expect it:game.load.image('ground_1x1', 'assets/tilemaps/tiles/ground_1x1.png');game.load.image('walls_1x2', 'assets/tilemaps/tiles/walls_1x2.png');game.load.image('tiles2', 'assets/tilemaps/tiles/tiles2.png');map.addTilesetImage('ground_1x1');map.addTilesetImage('walls_1x2');map.addTilesetImage('tiles2'); Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 It's because the loader/load tilemap json example hasn't been updated It should use the new format. Will fix it now. Pixelguy 1 Link to comment Share on other sites More sharing options...
stevenb Posted January 14, 2014 Share Posted January 14, 2014 Very nice! I've been using Phaser for some time now, and I like it very much.Is there a way to do different bounding shapes with the new physics system, such as circles?I'm seeing some tests and typescript code in that area, and the P2.js has some examples, but I'm not sure how to integrate that into my game (ball game) P.S. Some of the examples (Games > Tanks/matching pairs/wabbits) also need a code update bog 1 Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 We're still restricted to AABB for the current system, sorry. But full p2.js integration will start very very soon. tackle 1 Link to comment Share on other sites More sharing options...
stevenb Posted January 14, 2014 Share Posted January 14, 2014 Ok thanks setting Sprite.input.useHandCursor = true; Generates an exception Uncaught TypeError: Cannot read property 'style' of undefined phaser.1.1.4.js:17231 Phaser.InputHandler._pointerOverHandlerphaser.1.1.4.js:17231 Phaser.Pointer.movephaser.1.1.4.js:16007 Phaser.Mouse.onMouseMovephaser.1.1.4.js:15315 _onMouseMove Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 Had you enabled input on the sprite before calling that? Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 Everyone - I've a quick question about tilemap data. Can any of you think of a reason why you would want a specific tile in your map to have its own collision handler? When I say a specific tile, I literally mean "the tile at x: 40, y: 23 should have a callback", i.e. the callback is bound to the location of the tile and NOT the graphic the tile is using from the tileset. In tilemap data the maps are built up from tile index values, so there might be 100 tiles in the set and the map data would literally be rows of numbers between 0 and 100. Right now I've got it set-up so that a tilemap can have properties on a location basis, which means lots of new little objects are being created when the map loads (on Phaser.Tile object for every tile in the map). I could minimise this dramatically if I only created a Phaser.Tile object for every tile in the tilesets. But it will limit you, in that you can no longer say "collide this x,y tile" but you'd have to say "collide every single tile in the map whos index is X". Link to comment Share on other sites More sharing options...
Pert Posted January 14, 2014 Share Posted January 14, 2014 Can any of you think of a reason why you would want a specific tile in your map to have its own collision handler? When I say a specific tile, I literally mean "the tile at x: 40, y: 23 should have a callback", i.e. the callback is bound to the location of the tile and NOT the graphic the tile is using from the tileset.Level exits or "secrets"? There's always work around (ie if user.x == 40 && user.y == 23), but I suppose that's nice quick way to fire collision code.Or "events" - ie when player hits this position then enemies are spawned - in that case it's almost a set of tiles (x1, y1, x2, y2 ?) rather than single one. Link to comment Share on other sites More sharing options...
scoots Posted January 14, 2014 Share Posted January 14, 2014 Everyone - I've a quick question about tilemap data. Can any of you think of a reason why you would want a specific tile in your map to have its own collision handler? When I say a specific tile, I literally mean "the tile at x: 40, y: 23 should have a callback", i.e. the callback is bound to the location of the tile and NOT the graphic the tile is using from the tileset. In tilemap data the maps are built up from tile index values, so there might be 100 tiles in the set and the map data would literally be rows of numbers between 0 and 100. Right now I've got it set-up so that a tilemap can have properties on a location basis, which means lots of new little objects are being created when the map loads (on Phaser.Tile object for every tile in the map). I could minimise this dramatically if I only created a Phaser.Tile object for every tile in the tilesets. But it will limit you, in that you can no longer say "collide this x,y tile" but you'd have to say "collide every single tile in the map whos index is X". This is a tough one. While most tile map implementations probably don't need it, some do. For instance, I've written a digging game where the dirt tiles can take an arbitrary amount of damage, meaning I needed to track dirt tile "health" for each and every tile. The framework I used tracked tile properties on the tileset tile only, so I had to implement a tile data solution myself. Callbacks on the individual tiles would have made this much easier for me, data for the indivisual tiles even easier than callbacks. I don't think that most tile maps will need this, so if you think the overhead will hurt performance, I would not add this for every single tile. That said, if it could be something you could optionally turn on if needed, that might be a nice compromise if people think this is necessary. tackle 1 Link to comment Share on other sites More sharing options...
Arlefreak Posted January 14, 2014 Share Posted January 14, 2014 The timer is supper use full and works great Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 Thanks for that scoots - actually your use-case is exactly the reason I built it the way I've currently done it, because I was fed-up of the limitations of a tileset index based system. It doesn't hurt performance at run-time, it just means a little more memory is used up-front when the map is parsed, so I'm going to keep what I've got now. Cheers Link to comment Share on other sites More sharing options...
paperElectron Posted January 14, 2014 Share Posted January 14, 2014 Is there a likely release window estimate for this? I just started working with Phaser in general a few days ago, and would prefer to start working with the current API as soon as possible, provided a general release isn't a month or two away. Also are there current JSdocs available for this? Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 Assuming no-one finds any horrendous bugs it will be out this week. jsdocs have not been rebuilt for 1.1.4 yet, but are in the docs folder like usual. I tend to rebuild them just before we go live, but our jsdoc conf is included in the repo so you're welcome to rebuild them at any time you need too. Link to comment Share on other sites More sharing options...
paperElectron Posted January 14, 2014 Share Posted January 14, 2014 I tend to rebuild them just before we go live, but our jsdoc conf is included in the repo so you're welcome to rebuild them at any time you need too. Im not super familiar with jsdoc (just installed it from npm), but I'm getting some fatal errors trying to build it with node 0.10.20 on Debian 3.2.51 Ill just wait for you to pin down the changes and put them up officially. Link to comment Share on other sites More sharing options...
jcs Posted January 14, 2014 Share Posted January 14, 2014 when two sprites interact (collide) with each other, and the tilemap, odd things can happen. two specific instances, from my Nadion library sample: - I have a sprite that stands in one place and jumps up and down (side-scroller), and a player sprite that can move around. when the player sprite stands underneath the jumper and lets the jumper land on his head he can get "pushed" through the tilemap below his feet. this happens most repeat-ably when the player sprite has also jumped and landed just prior to the jumper landing on his head. - same circumstances, with the player sprite having jumped while standing under the jumper sprite (but not actually anywhere close to making contact with the jumper), the jumper sometimes detects a collision with something directly underneath itself (presumably the player sprite, even though it is some distance away) and jumps again off of "thin air". I've checked the current 1.1.4 upgrade work to Nadion into a "dev-phaser-1.1.4" branch (https://github.com/jcd-as/nadion) if you need it. I imagine any sample reproducing the two sprite scenario could reproduce it similarly though - i'm not doing anything interesting in the sample Link to comment Share on other sites More sharing options...
jpdev Posted January 14, 2014 Share Posted January 14, 2014 Hi, I have just upgraded (my one week old hobby jump & run) game to dev. I had some problems getting the tilemaps to work (since it was not clear to me, that the code now references names in the json file) - but once i realized that, it is quite brilliant (I think.) Question: Did you change gravity by factor 100 by accident or is this intended?(I went with 9.81 with the master-phaser, now I had to set it to 981 to get the old result, or something close to it. - No other values needed changing (like volcity etc.) I think.) All in all: I look totally forward to editing my level tomorrow.. since I can use more tilesets now in tiled and have them directly available in the game! Thumbsup! Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 jcs - yes I've been witnessing similar things today (sprites pushing other sprites through the tilemap). I think I've come up with a suitable solution, but will have to test it out now. Right now I've just got tile specific collision callbacks working though, so am tidying those up and then will look at this. It should also solve the problem someone else reported in the forum of 'stacked sprites' tunneling through each other. Link to comment Share on other sites More sharing options...
rich Posted January 14, 2014 Author Share Posted January 14, 2014 jpdev - gravity was incorrectly applied in 1.1.3 but is now done properly, so that's a fair point - I think people are going to have to tweak gravity values to get similar results back again. Link to comment Share on other sites More sharing options...
Pert Posted January 14, 2014 Share Posted January 14, 2014 Using phaser.min.js from dev branch and I get this error when I try to run similar test code to particle example.Using phaser.min.js from master branch works. Uncaught TypeError: Cannot set property 'x' of undefined phaser.min.js:12 c.Particles.Arcade.Emitter.emitParticlephaser.min.js:12 c.Particles.Arcade.Emitter.updatephaser.min.js:12 c.Particles.updatephaser.min.js:12 c.Game.updatephaser.min.js:5 c.RequestAnimationFrame.updateRAF haser.min.js:8 window.requestAnimationFrame._onLoop Link to comment Share on other sites More sharing options...
WeaveMN Posted January 14, 2014 Share Posted January 14, 2014 Got my hobby game ported over and haven't found any bugs, in fact things are working better. Some feedback:Thank you for adding fixedToCamera on Phaser.Text, allowed me to take out a crazy render texture thing I did to achieve the same effect.A nice to have with that would it if it worked like Sprite and took it's x/y position as the offset from the camera. Not that specifically setting the offset is difficult just extra code.Whatever you did with the TileMap collision cleaned up a whole bunch of random things I was seeing with sprites knocking other sprites outside the map, getting pushed through tiles, etc. Great work.Love the new way the tilesets work and are more bound to what is actually in the map file. Link to comment Share on other sites More sharing options...
Recommended Posts