Sprite Scaler

[Crow_T]

What about an option for "none?" Similar to gimp's none, where there is no interpolation method at all. I wouldn't mind that and it may be more system resource friendly.

In terms of this new algo it needs to do all the graphics, the combination one looks like the units are floating. http://i.imgur.com/yBtrwKH.png is the best one.

[iceiceice]

Hmm, so in this case we would just totally disable the zoom hotkeys? Because you can't zoom in and out if you can't rescale the sprites.

I guess similarly, could add an "xBRZ only" option, and make it lock the zoom values to only be an integer 1-5 in that case? If people think that would be good it would be an option.

[Iris]

“Interpolation: None” in the GIMP actually stands for nearest-neighbor interpolation.

[doofus-01]

Well, this is an interesting effect, and it would certainly be nice to have more IPF scaling options, but I'm not sure this really preserves the pixel-art-ness during scaling... It preserves the low-color crispness, but the precise placement is still lost (how can it not be?).

I guess I think it would be a nice addition as an IPF, even something to put in help-pages where it could be perfectly reasonable to find a larger, "painterly" image of the sprite, but as for zooming, count me skeptical that it's really an improvement. But then, I don't have anything like a retina display, maybe it's really dependent upon pixels-per-inch.

[zookeeper]

Personally, what I'd want to see if I ever used the zoom feature would be no interpolation of any kind (that is, nearest neighbour) for units and terrain. Bilinear makes things blurry and messy, xBRZ makes them painterly/vector'ish. I'd prefer to just see the pixels as they are.

[iceiceice]

Personally, what I'd want to see if I ever used the zoom feature would be no interpolation of any kind (that is, nearest neighbour) for units and terrain. Bilinear makes things blurry and messy, xBRZ makes them painterly/vector'ish. I'd prefer to just see the pixels as they are.

Okay, here I post another three images, this is 4x again, XBRZ vs nearest neighbor (no interpolation).

Nearest Neighbor only:
http://imgur.com/a/o3uNH#0

Units xBRZ, Terrain Nearest Neighbor:
http://imgur.com/a/o3uNH#1

xBRZ only:
http://imgur.com/a/o3uNH#2

Here's a similar group, with drakes (actually its the same game :p ):
http://imgur.com/a/84kxy#0

So, IMO, the xBRZ units tend to be less noisy and it's easier for me to see the unit. When you zoom things up this much without interpolation the pixelated aspects become starkly apparent. For instance, the crossbow is all jaggies and it's maybe hard to identify as such as first, but xBRZ aliases it and makes it smooth. Another example is, the face of the Drake Warrior. With xBRZ his face is quite clear, bright green and beak-like under his furrowed brow, with a nostril showing to us. With the nearest-neighbor version though, his nostril is quite hard to read, because there's a second group of darker pixels just above them. The eye is unsure whether to connect these features. Similarly many armor details, and the spikes on the drake burner, appear visually noisy compared to the smoothness of the xBRZ rendering.

I don't think one is objectively better than the other, and the NN version will also be a bit cheaper to render. (Although, the author of xBRZ seems to have put a huge amount of effort into optimizing his code, so I'm not sure if it's that much cheaper.) But I know at least in my case I would prefer xBRZ results for unit sprites at least.

Note also that, the results of xBRZ for terrain right now have many artifacts, for instance the fords look odd, and the shadows of the castles also. I'm pretty sure this is because of shenanigans in the alpha channel, so please excuse for the moment...

[beetlenaut]

I'm convinced. I prefer xBRZ for everything.

[Crow_T]

I'm convinced. I prefer xBRZ for everything.

It is a great looking method, no doubt about it. Much better than the current one. I think nearest neighbor may be a bit harsh? It's tough to tell without spending some time playing, it's kind of like font rendering options in an OS in that regard.

Seems like there are some weird artifacts happening in the alpha areas in xBRZ. *whoops just read all of ice's post*

BTW the one castle tower top block thing looks wonky, never noticed that before

[iceiceice]

Just an update that I have merged the xBRZ branch, after some tweaks to the alpha handling. I have plans for more work in that regard but it looks not too shabby right now imo.

You can also now build master very easily with homebrew! Why don't you give it a try?

[Andrettin]

xBRZ seems to have been released under the GPLv3, wouldn't that make it incompatible with Wesnoth (which uses the GPLv2)? Or has it been released under the GPLv2 as well?

Ok I figured out what the problem was...

Spoiler:

Basically xBRZ was crapping up the alpha channel any time it blended colors, that program assumes that there is no alpha channel, and in fact zeros it out whenever it blends two colors. SDL treats 0 alpha as fully transparent. Also, our sprites have some alpha in them, if you ignore this you get bad results.

I wrote some code to handle this in a very crude way, it will need some more work.

Take two: http://imgur.com/a/VPALw#0

I also added some pics comparing the "~xBRZ" image path function (which is how I hacked it in) vs. the default wesnoth "~SCALE" function (which I'm pretty sure gives the same results for when you zoom in on game map.)

http://imgur.com/a/KgsZS#0

This looks really, really good. I didn't even know that this sort of scaling was possible.

[Iris]

The source code in question links to the latest version of the GNU GPL (that is, as of this writing, version 3) but doesn’t specify a version number. The GNU GPL v3 itself says that omitting the license version is equivalent to allowing usage under any existing or future version of the GNU GPL.

[Andrettin]

The source code in question links to the latest version of the GNU GPL (that is, as of this writing, version 3) but doesn’t specify a version number. The GNU GPL v3 itself says that omitting the license version is equivalent to allowing usage under any existing or future version of the GNU GPL.

Thanks for the clarification, but the source code nevertheless comes with a License.txt file which contains the GPLv3 text, wouldn't that mean that they specified a version number?

[Iris]

The source code doesn’t specifically instruct you to read the included license. Just like the fact that most software that’s said to be v2+/v3+ (according to the source code files) comes only with a copy of the GNU GPL v2 or v3 doesn’t prevent you from using a later version, I don’t think in this case we should be prevented from using an earlier version.

[iceiceice]

andrettin:

1. I had the same thought as you at one point, but I think shadowm is actually right.
2. It's moot, because I messaged the creator anyways and he explicitly gave me permission to add it to wesnoth.

[Andrettin]

Thanks for the clarifications, shadowm and iceiceice!