Open vantreeseba opened 7 years ago
What's the expected outcome for
sprite.shader = filter
only? And did it ever work as expected (in v2.7 w/o WEBGL_MULTI or in v2.6)?
@samme
Thanks for the response.
I think the intended behavior there is to replace whatever fragment shader is being used to render the sprite itself with the one supplied.
My intended usage is to create an empty sprite that has a custom shader applied and have the drawing done through the shader without having to supply an actual texture to the sprite. (For lasers/etc.)
If you use Phaser.WEBGL as the renderer in the pen (it's updated to use this) and comment out the multi-texture option (or set it to false). The sprite.shader = filter; works as expected.
This works as expected in 2.7.x if you turn off multi-texture and texture priority as you can see in the screenshots below.
This is the expected behavior given no multi texture and no texture priority is set. Though child sprites are not rendered when a filter is applied to the parent, I'm not sure if this is intended behavior. (You can see test3 has no text label.)
When you turn on multi texture rendering it starts doing some strange things. You can see this when test 12/13 share a shader that is used as a shader on test12 and a filter on test13.
When you turn on both multi-texture rendering and texture priority, some of the sprites fail to render at all when a filter is applied and they have texture priority set to them (test1 is this example as the texture d1 is in the texture priority list, as well as test12 and test13).
Please let me know if this clarifies the issue or if you need more information.
Appears fixed by #641
This Issue is about filter behavior when using WEBGL_MULTI renderer and multitexture: true.
When used as a shader (sprite.shader = filter) it has no effect. When used as a filter (sprite.filters=[filter]) it works fine.
When used as both a shader and a filter, the sprite is rendered with strange colors.
When used as a filter on a sprite that shares a texture with another sprite, the second sprite (without the filter) is not rendered correctly.
When used as a filter, and then a shader with both shared and unshared textures, it works correctly (but sprite with filter does not render child elements, while sprite with shader does).
This issue is related to / duplicate of #211 but with more examples of the behaviors.