What is it with vTextureCoord (shaders)

[ben0bi]

So, I have set up my first shaders which just change colours.

Now I wanted to make a gradient shader but it won't work right.

It says: vTextureCoord is between 0 and 1. It is not. I apply the shader to some 16x16 Images, scaled to 2, and coords are way under 0.5.

To get the ALMOST right coordinate, I had to multiply it with 16. But also then, the gradient was a few pixels away from where they should be.

With x, it works "almost" right, but with y it works...not right. It's 1 in about the first quarter. (with *16.0, else it is black)

Can anyone explain that to me? PS: The screen is in a div with varying size (x) and 400px height.

It SHOULD work with that one, but if I copy that code, the above behaviour is given.

http://codepen.io/anon/pen/ORgkgY (not from me)

Thanks for your reply. Code is at work place, I will post it soon.

[ivan.popelyshev]

According to https://github.com/pixijs/pixi.js/issues/2867 point number 2, pixijs v4 has special thing called "mapCoord". If you edit your shader similar way to that thread, it will work just fine.

 ,

[ben0bi]

I found a solution to this. (Still using pixijs v3)

In another post on another page, it stated that the first filter in the filter array does it wrong but if you add the shader a second time, it will work.

I did NOT use that solution, because there is a .shader variable. Using this, vTexCoord works just fine.

MySprite.filters = [shader, shader] <-- the mentioned fix, which I do NOT use.

MySprite.shader = shader <-- This works just fine. But you can use just one shader. I need only one shader so this is fine.

Maybe we can use multiple "simple" shaders in the .filters array and one "complex" shader in the .shader variable. I hope the two do not overwrite each other.

[xerver]

There is a difference between the shader and the filter. A filter is run as a "post processing" step after the sprite renders itself normally (to a framebuffer). The shader property replaces the shader the sprite uses to draw itself, it is not run as a post-process step with the rendered sprite as the input.