Pixel art scaling algorithms

http://en.wikipedia.org/wiki/Pixel_art_ ... algorithms

Linear interpolation is one thing, but if I'm not mistaken these are a little bit different.

I first discovered these in emulators such as ZSNES. They can make pixelly 8-bit graphics look very smooth; like something that might be used in a Flash game.

Is there any way these could be used in Construct?

Not sure if that would be viable for real time rendering, but you can always do some pre-processing before you load it up.

Still there are some times when a real time interpolation would be nice, like when you get some "jaggies" doing rotations.

The crispify effect does something like that

these algorithms aren't useful unless you're doing exact 2x or 4x, which is normally not the case in a 3D accelerated environment. Also, I believe (not really sure though) that the algorithms are not pixel-shader friendly.

Dunno about getting them to work in Construct, but I wouldn't count on it.

Also, I believe (not really sure though) that the algorithms are not pixel-shader friendly.

And here I was going to suggest giving that a stab. Oh well. Maybe it could work, though?

I gave it a try once and I couldn't figure it out.

Basically the algorithms go pixel by pixel, while pixel shaders go texel by texel. 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.

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.

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.