AGAL: Calculating screen space position in fragment shader

Question

Before I define my problem in more detail, I think I should begin by explaining how I've set everything up.

Basically I have a simple plane mesh, defined as such (x, y, z, u, v):

_vertices = Vector.<Number>([
    -1, -1, 0, 0, 0,
    1, -1, 0, 1, 0,
    1,  1, 0, 1, 1,
    -1,  1, 0, 0, 1
]);

_indices = Vector.<uint>([
    0, 2, 1,
    0, 3, 2
]);

Nothing fancy going on here. But, the way I render this is where it all falls down. It's rendered by using two render passes; the first one is a simple fragment shader that simply copies a color to the output and renders to a 512x512 texture. Still, everything is working fine. It's in the second render pass my problem lies.

The second, and final, render pass, renders the same geometry, but the color of the fragmen (pixel) should be fetched from the texture rendered by the first pass. And that is where my problem comes in, I need a way to correctly calculate the position of the current pixel in screen space coordinates, or UV coordinates to be exact, so as to correctly extract them from the texture.

I've done some research on how to calculate this position, but somehowe I've ended up creating a kaleidoscope-like effect. This effect, however, is only apparent when rotating the mesh on the X or Z axis, but not Y axis, as shown here

Rotation comparisons

The fragment program used for the second pass, the one that creates this effect, looks like this

div ft0.x, v0.x, v0.w    // Divide vertex positions (v0.xy) with clip-space position (v0.w)
div ft0.y, v0.y, v0.w    // to obtain screen coordinates as -1,1

mul ft0.x, ft0.x, fc0.x    // Multiply positions (ft0.xy) by 0.5 (fc0.x)
mul ft0.y, ft0.y, fc0.x 

add ft0.x, ft0.x, fc0.x    // Finally add 0.5 (fc0.x) to positions (ft0.xy)
add ft0.y, ft0.y, fc0.x

tex ft1, ft0.xy, fs0 <2d, nearest, repeat, nomip>    // Simply copy the pixel at (ft0) from the render buffer (fs0)
mov oc, ft1";

On a final note, I'm quite new to all this. So I might be missing something obvious and as such I apologize in advance.

And if you want to have a look at the code in all its non-existing glory, the Github repo can be found here.

Answer 1

Using PIX I found out that the Y position that was being passed to the fragment shader was inverted, compared to regular Flash coordinates. Such that the top of the screen is 1, and bottom is -1, instead of vice versa. By simply negating the Y value before doing any screen position calculations, it now works flawlessly. I'm not sure if this is a software or hardware issue on my side, or if this is found elsewhere, but at least it works!