Pixel art scaling algorithms

For questions about using Classic.

Post » Thu Sep 09, 2010 5:18 pm

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?
Image
B
225
S
27
G
13
Posts: 1,774
Reputation: 18,024

Post » Thu Sep 09, 2010 5:38 pm

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.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Thu Sep 09, 2010 6:28 pm

The crispify effect does something like that
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Sep 10, 2010 12:41 am

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.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Fri Sep 10, 2010 5:37 am

[quote="madster":2bzcau2e]Also, I believe (not really sure though) that the algorithms are not pixel-shader friendly.[/quote:2bzcau2e]

And here I was going to suggest giving that a stab. Oh well. Maybe it could work, though?
B
16
S
8
G
4
Posts: 136
Reputation: 3,144

Post » Sat Sep 11, 2010 1:24 am

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.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Sat Sep 11, 2010 4:08 am

[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.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242


Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 3 guests