ID:2122142
 
Hi all, iv'e been working on a little feature in SS13 which adds some icons of a somewhat large size, and scales them down by setting the transform of the image at runtime

In Byond 509, this worked perfectly. The image was scaled down to the desired size with minimal loss of detail, and was essentially an area of higher pixel density than the rest of the world

But before i could merge this, we updated our codebase to byond 510, and something changed, its completely broken. Image scaling seems to have been drastically changed

Now when the image is scaled down, byond seems to cut random pixels out of the icon to make it fit as it scales, maintaining the pixel density and completely destroying the detail. My icons have the same pixel density as the surroundings and they look awful.

Does anyone have any idea what changed to cause this? Is it something i can fix through code or client settings?

Here's an example of one of my icons at normal size
http://i.imgur.com/e5y56ao.png

and here's how it looks ingame right now, scaled to 0.4
http://i.imgur.com/8UugDax.png

And here's how it looked in byond 509, note the preserving of details:
http://i.imgur.com/J8smlwq.png

In the current version, the C is distorted and the silver pips are just gone. This has been utterly destroyed by whatever new thing byond is doing

Rather than simply downsampling the icon and rendering it as best as the monitor can allow, byond is cutting out pixels to maintain pixel density with the rest of the world, and this seems to have broken the ability to make more detailed objects in the same space

This is not how it worked in byond 509, that's the most critical thing here. Something has changed and broken it, and broken content with it. i really need an explanation and hopefully a workaround

Why is this happening?

It might be relevant how i'm doing it, in case different code options produce different results:
//-------------------
hud_list[ID_HUD] = image('icons/mob/hud_security.dmi', src, "hudunknown")
hud_list[WANTED_HUD] = image('icons/mob/hud_security.dmi', src, "hudblank")


//Scaling down the ID hud
var/image/holder = hud_list[ID_HUD]
holder.transform *= 0.4
holder.pixel_x = -20
holder.pixel_y = 0
hud_list[ID_HUD] = holder


holder = hud_list[WANTED_HUD]
holder.transform *= 0.4
holder.pixel_x = -20
holder.pixel_y = -10
hud_list[WANTED_HUD] = holder
//---------------

This is the relevant parts of the code. We basically create an image, and then apply transforms and pixel offsets to it afterwards

The base icon file is 32x32, i'm scaling the image down to a screen area of roughly 13x13 pixels. Byond pixels that is, it takes a far larger number of actual pixels on any monitor and there's easily room to render more detail. Byond seems to be scaling the image down to 13x13 first, losing pixels as it goes, and then blowing that up into the onscreen size, which is dumb and destructive

What's even worse, is the original 509 image linked above, that's even smaller - its a 16x16 pixel image scaled to 65% (10.4 pixels). I'm certain this isn't responsible for it though, i checked it before and after the 510 update with no changes. whatever 510 has done to image scaling has caused this and it looks awful

Can i do anything about it?
The rendering code changed in 510, but it shouldn't have changed transforms to use nearest-neighbor interpolation. Something ain't right here.
In response to Lummox JR
That wasn't intentional..? if not, it should be.
In response to Lummox JR
Lummox JR wrote:
The rendering code changed in 510, but it shouldn't have changed transforms to use nearest-neighbor interpolation. Something ain't right here.

think its a bug?
it does look like that's whats happened
While it's was unintentionally done, it was also highly requested (using any other interpolation on pixel art is no bueno), so most of us don't want it fixed. It's just a shame people came to rely on the other interpolation method for things.

You might get hung up by the sack if you talk Lummox into fixing it, so it might be more ideal to find a way to make it look purdy with the existing method :)
I haven't seen this in action myself, so I don't even know how I'd address it.
can't we have a choice in how the scaling is done, instead of forcing one method or the other?

Breaking content is never a good thing, i think that should have been considered before changing it. Even if the old way didn't please everyone, at least they knew how it worked and already implemented workarounds. Changing the function of it now means people who already used it in its existing state, now have to go back and revise their work.

And how is nearest neighbor more desired than what was being used previously? On low resolutions it simply destroys detail, i'd argue blurring things gives a better appearance
In response to NanakoAC
NanakoAC wrote:
can't we have a choice in how the scaling is done, instead of forcing one method or the other?

Short answer: maybe. Right now I'm not sure why you're seeing the behavior you're seeing; it doesn't happen in my own tests. I wonder if there's some kind of default behavior happening here that I'm not overriding correctly.

I did a little investigation and found that I can control the sampling behavior after all, so I should be able to address this more fittingly in a future release.

Breaking content is never a good thing, i think that should have been considered before changing it. Even if the old way didn't please everyone, at least they knew how it worked and already implemented workarounds. Changing the function of it now means people who already used it in its existing state, now have to go back and revise their work.

As stated above, the change was not intentional--and it did not show up in my own environment.