Release v2.13.3 introduced strange image/render batching issues

[スィルヴァン]

The latest release improved performance with #641 but also introduced strange image batching behavior, see screenshot below.

• Phaser version(s): 2.13.3

• Live example:
  
  (https://tarutarolegends.com/ but I had to roll it back to version 2.13.2)

• What steps produce the bug: use game.renderer.setTexturePriority (+ picture atlas) with newest release gives strange batching behaviors

• What should happen: pictures should not get mangled up
  

• What happens instead: mangling of pictures

Please, have a look, I am also gonna investigate further asap. THX

[スィルヴァン]

I kept analyzing it and I am sure that the whole issue is connected with #641 + texture batching and it is also certain that setTexturePriority did not have those strange effects with version v2.13.2. Now some textures get batched wrongly and mixed up and some texture just don't even bother to appear.

1. setTexturePriority + v2.13.2 => no problem
2. setTexturePriority + v2.13.3 => displaying textures wrongly or not at all
3. setTexturePriority turned off + v2.13.3 => no problem

above the barrel and the drag weapon background are missing

here the kappa enemy is getting mixed up with the items picture atlas

...and the whole issue is even not consistent between devices...

@samme + @photonstorm , I would say that the latest release is not usable for games which use texture batching (setTexturePriority) but we would have to try to reproduce this with an other game.

[スィルヴァン]

@jamieallen1234 I would like to have an exact description why you made the breaking changes at #641 and why the following would have become obsolete:

bc4ab92
if (PIXI.WebGLRenderer.textureArray[baseTexture.textureIndex] != baseTexture)
+
if (PIXI.WebGLRenderer.textureArray[textureIndex] != baseTexture)

obviously, this broke my whole texture batching, as you can see above.
@samme + @photonstorm , I understand that phaser-ce has no priority anymore, but there still are some Patreons like me, who hope that Pull requests are handled with care. THX!

[samme]

I had assumed that multi-texture rendering had never worked entirely correctly (#231, #232) and that most authors weren't using it.

#641 solved the outstanding problem of poorer WebGL performance compared to Phaser 2.6.2 (#356). I should have marked it a breaking change.

If we revert #641 then we'll reintroduce some multi-texture bugs (#211, #230, #231, #232).

[スィルヴァン]

@samme , did you look at the code changes made at #641? PLEASE, could anybody @photonstorm or @englercj answer why those two big IF-blocks (bc4ab92#diff-265a5e202468899001aca007a9da7cba) were written/necessary? For me #641 looks just like a hack, removing important blocks of code for the sake of a little performance and breaking image batching.

[Richard Davey]

The majority of the changes in #641 looks fine, although I can't see the reason for moving the FastSpriteBatch texture index check to outside the children loop. I also can't see why the if blocks were removed from the WebGLSpriteBatch file. SpriteBatch is a different path entirely to FastSpriteBatch, so removing them literally removes multi-texture support for any sprites using that path.

If someone has a small example I can test with (ideally made using assets from the examples repo), then I can look at this further.

[samme]

I don't have an example reproducing the bug. https://samme.github.io/phaser-examples-mirror/sprites/multi%20texture%20example.html looks correct.

[スィルヴァン]

I made a simple example: https://github.com/Weedshaker/phaser-ce_issue-644 the result can be seen here: https://weedshaker.github.io/phaser-ce_issue-644/

As expected the behavior between the two version is different.

[スィルヴァン]

@photonstorm , do you need anything else? It would be fantastic if you could help us here.