Sprite with GLSL filter stuck at viewport boundary (not moving offscreen)

[scottwwh]

Hey there,

 

I'm just getting started with Phaser, and am looking at GLSL shaders (also for the first time) to see how they can be applied to sprites for effects on characters, backgrounds, etc. I ran into behaviour today that's likely a function of how GLSL works, rather than Phaser itself, and probably not the ideal approach. In any case, I'm hoping that someone can confirm one way or the other.

 

Currently, my game has:

• A TileMap background using two layers using different values for scrollFactorX/Y
  
• A Sprite for the player with a filter applied, which is being rendered correctly (although the sprite graphic itself has disappeared; more on this later)
  

What's odd is that when navigating through the map and the filtered sprite reaches a viewport boundary, it remains "stuck" there rather than moving offscreen. Since the shader example I'm using has no knowledge of the game, and it looks like the sprite is simply unmasking the shader output, I'm wondering a few things:

• Am I right to assume that this doesn't work for good reasons? (If so, what are they? )
  
• Assuming that I need shaders (versus a sprite sheet) for elements that may venture offscreen, should I be manually passing rect data to the filter that tracks the shapes I want filtered, separately from the sprite itself?
  

I'm looking forward to any insight that folks can share, so let me know if I can provide more details.

 

Thanks!

[wayfinder]

Sprites have knowledge of the world boundaries. Tilemaps will set those boundaries to their own, as far as I remember. As a test, try setting game.world.bounds = null after you create the tilemaps and see if that fixes it.

[scottwwh]

Thanks for the suggestion! While it didn't have an effect (the sprite still got stuck at viewport edge, not game bounds), I found the issue.

 

The Gray filter example didn't exhibit the problem, and after writing a quick test, it looks like the absence of vTextureCoord/uSampler variables might have caused the problem, which makes sense as neither of the other filters I tried referenced a sprite with its own coordinates. Looks like I have more reading to do, and in the meantime, have attached the sample code for anyone that's interested.

 

test-filter.zip