Align graphics to pixels when scaling

[sparr]

Fill a belt with an item whose graphic has small lines, like a circuit board. Zoom out.

If you set your zoom to an integer >=2 then every circuit board is pixel-identical to every other circuit board. At zoom 1 most of them will be identical, except on belt corners.

If, however, you zoom to a non-integer zoom, particularly <1, then you'll see different "versions" of the sprite depending on how its position lines up with the pixels on the screen. And if the sprite is moving across the screen, such as on a belt, then those details will change every frame. This is easiest to see by turning the game speed down, so that you can watch individual frames.

Demonstration starting with zoom=1 so things only change on corners, going to zoom 0.9 where every sprite changes almost every frame: https://www.youtube.com/watch?v=-KtmCmFrniQ

It would be possible to render sprites up to half a pixel out of place so that they always line up with the screen pixel grid. I think this very minor offset of location would be well worth the visual consistency it would provide.

[ssilk]

This is due to no longer support of multisampling.

See viewtopic.php?f=80&t=22760&p=142739&hil ... ng#p142739

There is no other way to do this correctly. You can turn on multisampling if you edit the config directly, but that is not supported!

Cause this is directly dependend from that support I move it to won't implement, I think it's at the same time clear, that everybody (even the devs) would like very much to have multisampling, cause it will look much better in the described situations.

[sparr]

There is no other way to do this correctly.

My suggestion is to round the x and y screen coordinates to the nearest integer before drawing. So instead of trying to draw a sprite in four successive frames at x=0 x=1.3 x=2.6 x=3.9 and getting different pixel samples each time you would draw it at x=0 x=1 x=3 x=4.

I'm not sure if this meets your idea of "correctly". There's a chance it would look "jerky" by one pixel, but I don't think that would be worse than what happens now.

I obviously can't test this. I hope a dev finds time to throw this into a test build and say whether it looks good or not in practice.

[orzelek]

From what I can see this is not lack of multisampling.

It seems that item icons on ground are rendered using linear interpolation. This basically means that for each pixel OpenGL will select closest point of icon and render whole pixel using that color.
Rest of stuff like belts under it are using nearest mapping that interpolates along the texture - this leads to blurring effects but makes stuff look better from afar.

[sparr]

From what I can see this is not lack of multisampling.

You're right, it's not technically that, but when we lost multisampling we also didn't get any other sort of sampling.

It seems that item icons on ground are rendered using linear interpolation. This basically means that for each pixel OpenGL will select closest point of icon and render whole pixel using that color.

You've confused nearest-neighbor and linear interpolation. Even linear would look better than what we have now.

[orzelek]

From what I can see this is not lack of multisampling.

You're right, it's not technically that, but when we lost multisampling we also didn't get any other sort of sampling.

It seems that item icons on ground are rendered using linear interpolation. This basically means that for each pixel OpenGL will select closest point of icon and render whole pixel using that color.

You've confused nearest-neighbor and linear interpolation. Even linear would look better than what we have now.

I'm pretty sure that we are seeing is linear one - since thats the only way to get that kind of pixel look (without actually drawing the stuff as lines). Altho the fact that some parts get missing I have no idea how it's happening. Other things that game renders are using nearest I think.