Phaser 2.2.0 Release Candidate 11 - Please Test!

[rich]

Yeah it hasn't worked since Pixi v2. Will have a look, but am expecting this to be a deeper issue.

[neurofuzzy]

I've created a fiddle to test my current tilemap implementation. The example below is using 2.1.3:

 

http://jsfiddle.net/zq8hn23g/2/

 

** EDIT url updated - that should not say hello world (I'm new to JSFiddle)

[rich]

Ok I've spent an hour looking into this, and basically I'm concluding the new version of Pixi just can't handle it yet. I've tried all sorts of things - from flagging the texture as invalid (causes an internal Pixi error), to calling generateTilingTexture directly on frame change (causes an internal Pixi error), to even writing over the canvasBuffer (causes it to render as black, it appears the baseTexture.source is incorrectly bound). I'm going to have to give up on this for now I'm afraid, but may return later and compare what's changed between Pixi 1 and 2 to the TilingSprite specifically.

[rich]

I have to add: I do find it frustrating being unable to tell if the bugs are my fault or not. I must spend so much time inside the guts of Pixi verifying it one way or another!

[neurofuzzy]

Well thank you so much for looking into it. It's not a huge concern of mine at this point.. I can work around it for the time-being. 

 

My biggest concern is the new TileMap implementation. I hope that the culling issues can be resolved. Let me know if you can't reproduce the issue:

 

Here's that link again:

 

http://jsfiddle.net/zq8hn23g/2/

 

EDIT: I've added an example that uses the latest dev build of 2.2.0. This does demonstrate the bug. It misses tiles in Chrome on drag and disappears randomly in Safari.

 

http://jsfiddle.net/zq8hn23g/3/

 

UPDATE: The bottom missing tiles in Chrome appear to be due to the fact that I am trying to shoehorn 16x64 tiles into a 16x16 map (for performance reasons I am striping my cells. I may simply need to write a patch for my particular use-case. But, the Safari issue still remains. Safari seems to be clipping everything BUT the edge tiles.

[rich]

I've created a fiddle to test my current tilemap implementation. The example below is using 2.1.3:

 

http://jsfiddle.net/zq8hn23g/2/

 

** EDIT url updated - that should not say hello world (I'm new to JSFiddle)

 

What should I be seeing in your fiddle? because it drags fine for me with no visual glitches other than the cropping of the top tile, which the comments said would happen anyway?

[rich]

Hi everyone,

 

Phaser 2.2 RC11 is now uploaded. There are new build files available and newly published docs too. The repo has had a bit of a tidy-up as well.

 

This build includes the new Tween Manager, which I'm really happy with both in terms of performance and features.

 

The Change Log is extensive to say the least, but well worth a scroll through.

 

Again if you can test anything at all with this it would be much appreciated. Especially things heavy on tweening.

 

I'm looking to release Phaser 2.2 on December 1st, so there is still another week of testing / burn-in to go.

[wayfinder]

Did someone change something about scale.pageAlignVertically? That seems to have broken between RC8 and RC11, at least in my project...

[valueerror]

is THIS  http://www.html5gamedevs.com/topic/10662-bug-or-feature-p2-physics-body-is-not-below-the-rendered-sprite/   something new in phaser 2.2 or was this "issue" always there?   

[rich]

@wayfinder - Yes ScaleManager has almost certainly been updated against between those version RCs. What code are you using to set-up game scaling in your project?

 

@valueerror - Nothing in p2 itself has changed, but Pixi Graphics has of course which may well be related to this? Hard to say, the p2 examples look fine, so what do I need to do to them in order to make it go weird like your screen shot?

[valueerror]

@rich:   took some time to strip down my whole game ^^  

 

here you are: http://test.xapient.net/phaser/offsettest/

[valueerror]

oh.. i forgot ;-)  click on the cow and hold the mousebutton to throw it around 

[CtlAltDel]

I have seen that behaviour in 2.0.7 as well valueerror. Where the debug body would be behind on the sprite.

 

Could it be that the position of the sprite is adjusted by p2 physics and then velocity is applied again? Then next loop it applies position again and some velocity. But that's just guesswork.

[valueerror]

what is behind is the p2 body and the debug image rendered over it in a different color is exactly on it..  as it should be...  you can see that the debug rendering is exactly at the physicsbody location because of the other sprite (the white rope) that points exactly to it's X ond Ycoordinates and in the exact center..

 

so if its possible to render a debug circle at the position from the p2 body.. it should be possible to render the sprite at the exact same position too.. right?

[CtlAltDel]

Not if the p2 body is not at the same position as the sprite. So the sprite is ahead of the p2 body. which might mean a bug (but if that is so, it's been a bug that has been in since 2.0.5 or so), I saw this behaviour as well when playing with p2 physics.

[wayfinder]

The physics update happens after the state update, so the physics body will be one step ahead, basically, as far as I can tell. For "balls to wall accuracy", as Rich entertainingly put it, Phaser has a preRender event (I think that's the name) that happens after physics, in which you could perhaps update the position of the sprite to match the physics body?

[wayfinder]

@wayfinder - Yes ScaleManager has almost certainly been updated against between those version RCs. What code are you using to set-up game scaling in your project?

 

 

In my Boot state:

this.scale.minWidth = 800;

this.scale.minHeight = 450;

this.scale.maxWidth = 800;

this.scale.maxHeight = 450;

this.scale.setSize();

this.scale.pageAlignHorizontally = true;

this.scale.pageAlignVertically = true;

this.scale.fullScreenScaleMode = Phaser.ScaleManager.SHOW_ALL;

this.scale.refresh();

[nkholski]

Rich, did you see my post about emitters/particles in the 2.2.0-RC:s? Sometimes emitters emit their particles at the top of the screen instead of the desired y-position, and it seems to occur randomly and somehow related to setBounds. Everything works fine with Phaser 2.1.2.

 

I've tried to hunt down what's wrong but haven't been able to find any solution (and the problem persists with RC11), but I found some more information that might be helpful to hunt down the bug.

 

The last link below demonstrates the problem. The emitters is initiated at y=293 and everything seems to work fine (for(var i in game.particles.emitters){console.log(game.particles.emitters.y)} in console always return only 293-values). I also checked the y-value of the particles in all relevant functions I could find in phaser.js but it also seems to be set correctly. However, I modified Phaser.Particle.prototype.update to detect when the y-value is to low and to compare with last y-value, and it reveal big jumps to the top of the screen. The problem occurs randomly but more frequently if I the workload goes up by resizing the window or letting console.log spit out hundreds of non-duplicate lines.

 

I use Chrome 38.

 

 

I still have issues with particles and RC7. I took some effort but I managed to narrow it down to be a problem when bounds is changed with setBounds to a higher y-value than 0, and that it seems to occur randomly.

 

Basic example without setBounds working with RC7: http://niklasberg.se/entityExplode/index.html

 

Modified example with game.height halved and bounds set to lower part of screen working fine with 2.1.1: http://niklasberg.se/entityExplode/indexBounds.html

Same as last one broken by shifting to RC7: http://niklasberg.se/entityExplode/index-2.2.0-rc.html

 

As you can see by the last example, even if all entities and thus emitters is created at the bottom of the screen stuff will fall from above occasionally. This seems to happen randomly. I log the y value in the console where the emitter will be created and it's constant.

[valueerror]

The physics update happens after the state update, so the physics body will be one step ahead, basically, as far as I can tell. For "balls to wall accuracy", as Rich entertainingly put it, Phaser has a preRender event (I think that's the name) that happens after physics, in which you could perhaps update the position of the sprite to match the physics body?

it looks more like the physics body is 3 steps behind

i think this behaviour is not intended so i leave it to rich to decide what to do..  the thing where it gets complicated for me is that    player.x and player.body.x are exactly the same.. so phaser thinks the sprite is where the body is but it's actually rendered elswhere...      

[rich]

wayfinder is right, the issue is that debug layer is rendered after the world has updated, after everything else has been drawn and all values have been calculated. So it's a whole frame (or more) ahead of the physics step. I.e. it renders where the next sprite render will occur. The body and the sprite are perfectly in sync, that isn't the issue, the issue is that the rendering of the sprite and the debug layer are far apart.

 

It's always been like this btw.

 

If the Stage.update runs after physics.update in the core game loop then both are perfectly in sync. This wasn't an option before though because the logic and renderer shared the same update, but actually now with the new timer I'm thinking it won't be much of an issue to swap them. I'll do some more experiments to see. It's one of those simple things where a 1 line code change can have potentially phenomenal and unforeseen consequences elsewhere.

[valueerror]

wait what?   sorry to sound stupid but can't follow you...  

what i see is a debug circle that is not able to catch up to its sprite.. it is behind not ahead..

 

in other words..   i see is a sprite (the white rope) and it's origin is exactly in the center of the debug circle (the colored transparent)  

in the code i pinned it to the sprite.x and y position (the cow) - and it works..  it is exactly where the sprite should be..

 

and then there is the other sprite (the cow) - thats the sprite that belongs to the debug circle (or vice versa) and it (the debug circle) is BEHIND (and so is the rope that should point at the center of the sprite not the debug circle)..  so how can the debug circle be painted where the sprite will be if the sprite is already ahead..  the debug circle follows the sprite.. not the other way around.

[rich]

Yes you're right, my bad - sorry. If you basically reverse everything I said in my post above it still applies and is the reason, just in the opposite direction!

 

The Sprites physics body is updated in postUpdate, which happens after the debug body has synced its coordinates with the sprites position (which happens in update). Hence it's always one step behind.

 

I'm thinking there is actually a woefully easy fix for this. Just testing something....

[rich]

Well that was so simple it was ridiculous: https://github.com/photonstorm/phaser/commit/667d477a16768657b0bee32e5e2b4b2e896e5632

[rich]

In my Boot state:

 

Ok I need to post some examples of how to use the new scale manager!

 

Rich, did you see my post about emitters/particles in the 2.2.0-RC:s? Sometimes emitters emit their particles at the top of the screen instead of the desired y-position, and it seems to occur randomly and somehow related to setBounds. Everything works fine with Phaser 2.1.2.

 

Looking at the example I wonder if it's a case of the particles being generated too close to the tilemap and with a high enough velocity to force them to tunnel through it and reset to the top? Does it still happen if you move your emitter up say 30 pixels?

[nkholski]

Looking at the example I wonder if it's a case of the particles being generated too close to the tilemap and with a high enough velocity to force them to tunnel through it and reset to the top? Does it still happen if you move your emitter up say 30 pixels?

 

I moved the emitters 30 pixels up in the example and fixed the x-position with the same results (updated the example online too). I noticed that if I add "game.world.resize();" in the console it will work as before but it wasn't needed in previous versions and I don't know why it would be necessary now. Is this expected? Also, if I do so game.world.bounds.width/height will be undefined.