Not scaling at all for me

[manadream]

Hello! Thanks for making this! I have tried to use this after failing to port a different AA pixel scaling shader, and this one is having the same problem, namely that it doesn't actually do any scaling. I downloaded it and ran it on love 11.4, 11.3 and 11.2. All the same. I am running love on Linux with a modern gaming laptop. Any idea why this might be happening?

[RNavega]

Hi. Just to confirm:

• You didn't modify the code in any way?
• Holding the Space key doesn't draw the scene upscaled?

[manadream]

Thanks for getting back to me so quickly! I double checked and I actually got the code from here: https://love2d.org/forums/viewtopic.php?t=89442 Seems like there's a difference in that version where you comment out a part of a line: love.graphics.draw(image, 0, 0)--, angleSin, SCALE[1], SCALE[2], 1.5, 1.5) So if I understand this correctly, what you want to do to use this shader is to scale whatever you are rendering normally using love's scaling with "linear" as the filter, and have this shader set as the rendering shader that is used for that draw operation. Is that correct?

[RNavega]

Seems like there's a difference in that version where you comment out a part of a line

Oops, that's an oversight, thanks. I've removed that forum attachment since it's a worse way of distributing code -- the code here on Github is always the latest and best.

So if I understand this correctly, what you want to do to use this shader is to scale whatever you are rendering normally using love's scaling with "linear" as the filter, and have this shader set as the rendering shader that is used for that draw operation. Is that correct?

That's right. Note that you don't have to set the mag filter to "linear" every time, as that's already the default mode.

This shader can only do its magic when the sprite being drawn is under 'magnification' (the sprite is upscaled, so the texels from the texture that it uses are drawn bigger than the screen pixels). If you're drawing the sprite at "identity" (AKA default) scale, then its texels have the same size as screen pixels and the shader won't make a difference.

So you draw your pixel-art sprite(s) with some scaling going on (whether using a global scale like love.graphics.replaceTransform() which affects everything, or a local scale like love.graphics.draw(image, x, y, r, *sx*, *sy*, . . . )), while this AA shader is the active one.
The shader does this: for every screen pixel produced by the sprite, if that screen pixel is entirely within a texture texel from the sprite, then the screen pixel is exactly that color. If, however, the screen pixel is at the edge between neighboring texels (horizontal texel neighbors for the U coordinate, and vertical texel neighbors for the V coordinate), then the screen pixel will use the blended color between those neighbors based on where the screen pixel is in the "transition zone" between the neighbors.

In this image below, the black grid are screen pixels, and there's a huge rotated sprite, of which you can see two texels from it: the red and purple areas. Screen pixel A is fully red since it's entirely within the red texel, and screen pixel B is inside the transition zone between the two texels, so it's a linear blend between them depending on where it is on that transition zone. The width of that transition zone (SMOOTH_SIZE in the shader code, a float value of screen pixels) defaults to 1.0, for a perfect antialiased result, but a bigger value leads to smoother results.
Try 1.5, 1.75, 3.0 etc. More info in the shader code comments.

[RNavega]

Hm, actually it's best to keep this open as other people can read it too.

[manadream]

Thanks so much for the detailed explanation! That helped me understand what these kind of shaders are doing, and I was able to get it to function for my use case. Thanks again :+1: