[Disc] - vTex is Y-up for layers & for 2nd pass on sprites?

It's very possible I'm doing something wrong here, but it looks like the Y component of vTex is sometimes Positive upwards and sometimes Positive downwards, with the origin sometimes at the bottom-left, and other times at the top-left, depending on what you're applying the effect to, and how you're applying it.

For a sprite the vTex coord system seems to have its origin at the top-left of the sprite, with the (1,1) point at the bottom-right of the sprite, making Y-positive-down, which is what I would expect. However, this seems to only be true for the first effect placed on the sprite. All subsequent effects applied to the sprite seem to have a flipped and scaled coordinate system with the origin at the bottom-left of the screen (the screen, not the sprite) and the (1,1) point at the top right of the screen, with Y-positive-up, instead of down like it is for the first effect.

To try to better understand what was going on, I created an effect that simply places the X and Y values of vTex in the R and G channels respectively. Thus, red increases with positive X, and green increases with positive Y.

gl_FragColor = vec4( vTex.x , vTex.y , 0 , 1 );[/code:nucr3ubz]
You can download the effect here to try it for yourself:
[url=https://dl.dropboxusercontent.com/u/38240401/Public%20Distribution/Construct2/Effects/fi_effect_ShowUV.zip]https://dl.dropboxusercontent.com/u/382 ... ShowUV.zip[/url] 

When I apply this effect to sprites, I get a black corner in the top-left of the sprite, with green increasing downward, and red increasing rightward, just like you'd expect, both colors maxing out at the bottom-right corner of the sprite. When I apply the effect a second time to the same sprite, I get a "window" onto a coord system where there is a black corner at the bottom-left of the screen (the screen, not the sprite), and green increases upwards until it maxes out at the top edge of the screen. Likewise, red maxes out at the right edge of the screen.

When I apply this effect to layers, I get a black corner in the bottom-left, with green increasing upwards, and red increasing rightward, both colors maxing out at the top-right corner of the screen.

This inconsistency in the coordinate systems seems to occur both in the editor and at runtime.

Again, I could be doing something wrong here, so I figured I'd run it by the forum. Any advice is welcome. If anyone want's to try it out and report back with what they find, you can download the Show UV effect above.

Huh, maybe some flipping happens in the effect chain. It shouldn't matter though, since if everything is flipped then the end result is the same as if it never were flipped.

I may be thinking about this wrong, but I think the shader I linked to shows that the coordinate space flipping and scaling does not result in everything coming out as if it were never flipped. That is, at least on my computer and version of Construct 2, the end result appears to be different depending on what the shader is applied to and how it is applied.

My specs are:

Construct 2 version: r173 64-bit.

Previewed in: Firfox & Node-Webkit (same behavior in both)

OS: Win7 x64.

RAM: 16 GB

GFX: Geforce GTX 780 Ti

Brief disclaimer: I always feel a bit uneasy about describing a potential problem, because I don't want to come off as complaining. My feeling is that Construct 2 is awesome, and thanks to the effort of the devs, grows steadily more awesome with each release. So, I'm only bringing up the coordinate space issue because if it really is a problem, that isn't just on my computer, it may eventually be one more place C2 has room to expand it's aforementioned awesomeness.

Again, I could be thinking about this coord space thing wrong, but it doesn't look to me like there is any way to reliably address a desired location on an arbitrary object (layer, sprite, etc) in the way you could in Construct Classic.

The issue I'm running into at the moment is that I'm trying to recreate a pretty simple elevation gradient effect I created for Construct Classic, but presently in Construct 2 the coordinate system doesn't necessarily face a consistent direction, or consistently refer to the bounding box of the object being processed.

A number of my Construct Classic shaders that I'm trying to port to Construct 2 won't work without a coordinate system that behaves consistently. What I mean by consistent, is that the origin (0,0) is always in the same corner of any object and the (1,1) point is always in the opposite corner, whether you're dealing with sprites or layers, and whether the effect is the first in the chain, or later in the chain.

At the moment, if I say get the object's color at (0,0) I could be referring to the bottom-left corner of a layer, the top left corner of a sprite (only if it's the first effect in the chain), or a point that may not be anywhere near the sprite's bounding box, if the effect is second or farther on in the chain. Although depending on the location of the sprite within the layout, (0,0) could also potentially refer to any point inside the sprite's bounding box as well, (since the coordinate space gets entirely decoupled from the sprite after the first effect).

By contrast, in Construct Classic, the effective (0,0) point was always the top-left corner of any object you were dealing with, and (1,1) was always the bottom-right, whether you're dealing with sprites or layers, and regardless of how many effects were in the chain.

As a workaround, I could try building in extra effect parameters that user's could use to compensate for the various possible coordinate spaces, but they would have to be things like "Enter the dimensions of your sprite only if this is the 2nd effect in the chain", "Enter the dimensions of the viewable screen area", "Check this box if this effect is being applied to a sprite", "Check this box if this is not the first effect in the chain" and "Check this box if this effect is being applied to a layer". This would require multiple layers of branching code to be placed inside the shader. But it could theoretically work. Though you might also have to pass the location of the sprite within the viewable screen area to the effect in order to resolve some of the 2nd-effect-in-the-chain issues.

Another possibility would be to make multiple slightly different versions of an effect to handle each case. I could make a Layer version, a Sprite-1st-effect version, and a Sprite-2nd-or-later-effect version.

Again, I don't want to sound like I'm complaining or criticizing here. And like I said, this may just be on my computer. I haven't had time to test it out on another machine, but the effect I linked to in the first post should show what I'm talking about if it's not restricted to my computer.