Phaser 2.2.0 Release Candidate 11 - Please Test!

[PingwinGames]

I'm trying out the latest version of Phaser (v2.2.0 "Bethal" - Built: Tue Dec 02 2014 09:04:18) and it would appear that json format tilemaps are now broken. 

 

In order to familiarise myself with Phaser, I was looking at this tutorial - http://html5hub.com/how-to-make-a-sidescroller-game-with-html5/

 

With Phaser 2.1 I came across an issue with the tilemap not scrolling unless it was running in Canvas mode instead of WebGL. Upgraded to 2.2 to see if that resolves the issue but now I get this error:

 

"Uncaught TypeError: Cannot read property '2' of undefined"

 

This is at line 70146 in Phaser.js when I call game.add.tilemap.

[Preece]

Hey Rich, very excited about these updates. I tried to update my game which uses tilemaps and hit a snag. Here is the full stack of errors.

 

Uncaught TypeError: Failed to execute 'drawImage' on 'CanvasRenderingContext2D': No function was found that matched the signature provided.phaser.js:70303

c.Tileset.drawphaser.js:69236

c.TilemapLayer.renderRegionphaser.js:69357

c.TilemapLayer.renderFullphaser.js:69429

c.TilemapLayer.renderphaser.js:68762

c.TilemapLayer.postUpdatephaser.js:21699

c.Group.postUpdatephaser.js:20236

c.Stage.postUpdatephaser.js:26514

c.Game.updateLogicphaser.js:26453

c.Game.updatephaser.js:46315

c.RequestAnimationFrame.updateRAFphaser.js:46299

window.requestAnimationFrame.forceSetTimeOut._onLoop

[InsaneHero]

Posted in the wrong place...

[InsaneHero]

Fixed-delta, render-independent physics sounds wonderful!

Is it now reasonable to expect the exact same initial scene (world?) to evolve exactly the same when run twice?

I've been putting off a project idea for a while now waiting for this! (a blend of angry birds, KSP, and the time slider from CodeCombat)

 

Possibly not at present but it's an interesting use-case.

 

I think currently you'll find it runs exactly the same provided the machine doesn't lag out too badly - but if it does then the physics will drop frames (along with all of the 'logic' updates - so your game will stay in sync with the physics) but the render continues to update and so do the time.now and time.time values... so if anything at all in Phaser or your code uses these numbers directly, the simulation could diverge on slow machines.

 

It might be worth running some quick tests to find out for sure - most of the logic is locked to a fixed time step so even skipping frames won't affect your simulation at all.

[InsaneHero]

I've got some leaks in my current project which I've been trying to fix so it doesn't slow down on low end devices after a few levels.

As part of this I changed all the sprite 'kill' commands into 'destroy' because I'm not pooling anyhow and I wasn't sure if those sprites were still lurking after kill.

Now I'm getting a crash in Animation.update

this.currentFrame = this._frameData.getFrame(this._frames[this._frameIndex]);

where this._frameData is null.

 

Here's the call stack:

 

Uncaught TypeError: Cannot read property 'getFrame' of nullphaser.js:52693 Phaser.Animation.updatephaser.js:52031 Phaser.AnimationManager.updatephaser.js:36851 Phaser.Sprite.preUpdatephaser.js:36861 Phaser.Sprite.preUpdatephaser.js:21530 Phaser.Group.preUpdatephaser.js:21530 Phaser.Group.preUpdatephaser.js:20122 Phaser.Stage.preUpdatephaser.js:26233 Phaser.Game.updateLogicphaser.js:26183 Phaser.Game.updatephaser.js:45971 Phaser.RequestAnimationFrame.updateRAFphaser.js:45955 Phaser.RequestAnimationFrame.start._onLooprequestAnimationFrame (async)phaser.js:45973 Phaser.RequestAnimationFrame.updateRAFphaser.js:45955 Phaser.RequestAnimationFrame.start._onLooprequestAnimationFrame (async)phaser.js:45973 Phaser.RequestAnimationFrame.updateRAFphaser.js:45955 Phaser.RequestAnimationFrame.start._onLooprequestAnimationFrame (async)phaser.js:45973 Phaser.RequestAnimationFrame.updateRAFphaser.js:45955 Phaser.RequestAnimationFrame.start._onLooprequestAnimationFrame (async)phaser.js:45973 Phaser.RequestAnimationFrame.updateRAFphaser.js:45955 Phaser.RequestAnimationFrame.start._onLoop

 

Previously I was getting an error in the Animation.onComplete signal code but I just updated to the latest dev branch and that one has been fixed (the check for _bindings being null).

 

It feels like Sprite.destroy isn't killing everything off, but after stepping through it a few times it certainly looks like it should be.

If I set a breakpoint to catch this error and then look further back up the call stack, I see that Sprite.preUpdate has recursed on a child sprite and if I step up one more level I can see that this loop:

    //  Update any Children    for (var i = 0, len = this.children.length; i < len; i++)    {        this.children[i].preUpdate();    }

has gotten weird because i = 0, len = 2, but this.children.length = 0 ... so it looks like one of the child calls has destroyed the parent.  Should that loop exit if preUpdate returns false maybe?

 

The structure I'm using here is an empty sprite with two child sprites at different offsets from it.  The children are running animations.  When certain game events happen, I destroy all three sprites starting with the two children, then the parent.

[PingwinGames]

The problem I reported would appear on further investigation to relate to tile sheets with spaces between the tiles. The problem went away when I switched to a tile sheet with zero spacing between the tiles.

 

The rowCount and colCount calculations in the updateTileData function look suspect to me as I don't think it will take into account the fact that there are only spaces between the tiles, for example, a tile image with 10 tiles across only has 9 lots of spacing.

 

Perhaps the calculations should be something like this:

 

var rowCount = (tileSpacing + imageHeight - this.tileMargin * 2)/(tileHeight + tileSpacing);

[InsaneHero]

To follow up on the crash I reported yesterday...

If you destroy a sprite with children during an animation callback (ie. onComplete) on one of the children, Phaser will crash.  The complete signal is called: from animation.complete, from animation.update, from animationmanager.update, from sprite.preupdate.

Destroying a sprite will of course destroy it's children, but sprite.preUpdate is looping on a memorised array length for the children array.  This means it loops out of bounds and crashes.

 

I'm just tracking back through the call-stack now to see if there is a natural place to return 'false' and abort the sprite.preupdate loop on the children in this case.  Alternatively, the loop could use the actual children.length value instead of memorising (less efficient, more safe), or we could add a further check to make sure that the index is in range (even less efficient as it's doing an additional check as well as calculating length each loop).

 

No, the animation update returns a boolean but that's used to indicate if the frame changed or not... so there's no great way to do this.  I think I'm working directly off the dev branch instead of a local clone (I can't push changes) so here's the fix:

Sprite.js  line 322:    //  Update any Children (NOTE: don't pre-calculate this.children.length, the children can be destroyed during a Signal callback inside this loop)    for (var i = 0; i < this.children.length; i++)    {        this.children[i].preUpdate();    }