[quote="madster":2xzut5us]Particularly in Construct (never tried writing shaders for anything else) they go in screen space, not object space as the algorithm goes.

So I have no idea how to even go about it.[/quote:2xzut5us]

You're not bound to screen space. That's what boxLeft, boxRight, boxTop, boxBottom, pixelWidth and pixelHeight are for

Example:

Tex.x / pixelWidth would give you the horizontal pixel index in the screen space.

Let's say you have a window canvas of 800x600, then pixelWidth would equal 1/800 or 0.00125

Tex.x is a value between 0 and 1. For Tex.x = 0.5 this would be 0.5 / 0.00125 = 400

If you want to know the relative pixel index just substract boxLeft: (Tex.x - boxLeft) / pixelWidth

boxLeft is the horizontal position of the left edge of the current object as a value between 0 and 1.

Let's assume it is 0.25 (which would be 0.25/0.00125 = 200 as pixel index). Then we have (0.5 - 0.25) / 0.00125 = 200, which is the relative pixel index from the left edge of the object.

One problem is that you could have situations where you sample a space between two pixels, you then get a mix of the two colors of that pixels. Often this is avoidable by rounding the pixel index value, but then you may sample a pixel more than once.

And when pixel sampling isn't important you can even normalize the object's dimensions, making it easier calculating:

float2 coord = float2((Tex.x - boxLeft) / boxWidth, (Tex.y - boxTop) / boxHeight);

now you have coordinates relative to the object, ranging from 0 to 1 (0 being the left or top edge of the object, 1 being the right or bottom edge)

One thing is important: With a pixel shader you're working on the final output not the input. You have to reverse think about those algorithms.