Shader takes UV coordinates of spritesheet after export.

Problem Description

UV coordinates (vTex uniform) give wrong results after having more than one animation (or animation frame) after exporting.

Attach a Capx

Effect: https://drive.google.com/file/d/1QFi5be ... sp=sharing

Capx: https://drive.google.com/open?id=1bhfsO ... NqGj4bZW0I

Description of Capx

Result of what can be seen is different before and after preview.

Steps to Reproduce Bug

Make 2 sprite objects in the project. Make it so one has 2 single-frame animations and the second has 1, fill them all with solid color Add the same effect with the same parameters (effect must use UV coordinates. I have used mine shader that is released on scirra store. I could send it through pm if it's needed) Export the game

Observed Result

The object with more animations is disorted and gives completely different result as it gave in preview.

Affected Browsers

• Chrome: YES
• FireFox: YES

Operating System and Service Pack

W10 with newest updates

Construct 2 Version ID

r250

Here are screenshots:

How it looks like in preview (and should after export):

How it looks like after exporting:

My assumption is that the exported project uses spritesheet's UV coordinates, and spritesheeting happens after export.

To prove it even further, here's the spritesheet the first object uses with shader applied to it.

It looks like the same "cuts" that were apparent in the previous image.

Your screenshots don't match the effect or .capx provided. Based on what you have provided, it's not a bug. vTex is the position in texture co-ordinates of the current fragment on the source surface. By design, this can be pretty much anywhere. With spritesheeting, this means the sprite image is no longer 1:1 with the source texture, and will instead be a subset of the texture. Also it changes in some other circumstances, such as you've found when you change opacity: in this case the effect compositor pre-renders the sprite to a viewport-sized surface with the opacity applied, and then processes the effect from a sprite-sized subset of the viewport-sized surface. This is necessary to ensure the shader processes pixels with the opacity already applied. This pre-draw step changes the co-ordinates of vTex. Normally this doesn't matter - if you use texture2D(samplerFront, vTex), you always get the right pixel. The shader you provided simply displays vTex as a gradient and you've pointed out the cases where it varies; these cases are by design, so this in itself won't be fixed.

What you probably need instead are uniforms that specify the source rectangle subset being processed. Then you can use vTex's position within this rectangle to determine the normalised texture co-ordinates ([0-1] range) within the subset actually being drawn, rather than relative to the entire source surface. Construct 3 provides the necessary uniforms with the srcStart/srcEnd uniforms, and even provides an unclamped srcOriginStart/srcOriginEnd rectangle as well to avoid effects changing as they clip against the viewport edge. Then in a C3 shader you can use a calculation like this:

mediump vec2 tex = (vTex - srcStart) / (srcEnd - srcStart);[/code:1j3hmbyw]
which calculates 'tex' as normalised co-ordinates within the rectangle being drawn. Using the srcOrigin variants gives you normalised co-ordinates which don't change as it clips against the viewport, which is usually more useful for anything other than sampling the background. E.g. if your shader drew a circle from vTex normalised to srcStart/srcEnd, it would squish up as it moves off the viewport, but using the srcOrigin variants ensures it looks consistent. (The manual covers this, and some other useful patterns, in the manual entry I linked to previously.)

Unfortunately, C2 doesn't provide the necessary uniforms. We did a ton of work on the effect compositor for C3, and it took a great deal of time and effort, it's some of the most complicated code I've ever written. C2 has around 80 built-in effects and we managed to get by without these uniforms. At this stage it's unlikely we could add these uniforms back in to C2, it's incredibly complicated and time consuming, and we did it along the way while upgrading the codebase for C3. These uniforms are essentially a new feature of the effects engine in C3 allowing for more consistent and better quality effects. Still it should mean you can write these effects and have them work as you need them to in C3.