Hi all, I don't want to rehash stuff that was discussed on the forums too much -- basically, I believe that there is a bug in how wesnoth 1.12 is scaling graphics in-game. However, it is somewhat subjective whether it is a bug or not -- if no one objects then I would like to merge this patch to fix it: https://github.com/wesnoth/wesnoth/pull/316
In brief: In wesnoth 1.12 there are two methods to scale images, a simple "nearest-neighbor" scaler which scales up pixels on an individual basis, yielding blocky, pixelated results, and a "bilinear interpolation" scaler, which blends nearby pixels, averaging their color and alpha values together. When scaling down images (zooming out) bilinear interpolation is generally the way to go, otherwise you are simply throwing away the color values of the majority of pixels. When scaling up images (zooming in), bilinear interpolation is not very good, because it blurs hard edges and surfaces, and IMO makes pixel art look bad. However, in 1.12 we currently use bilinear interpolation for both sprites and terrain. Here are some relevant forum posts: a user complaining about blurred pixel art: http://forums.wesnoth.org/viewtopic.php?f=4&t=40987#p575696 zookeeper expressing distaste for blurred pixel art: http://forums.wesnoth.org/viewtopic.php?f=12&t=41109&start=15#p577024 Indeed it seems possible that we are doing this accidentally, since lipk here posts that he thought we weren't actually doing this ever: http://forums.wesnoth.org/viewtopic.php?f=12&t=41109#p576979 (Note that the last two posts are from a thread discussing a proposed feature for master branch, not related to the pull request above which is for 1.12.) In my (very small) patch I change us over to use our nearest neighbor scaling routine for both units and terrain. In the pull request description I link to some screenshots showing before & after. IMO the nearest neighbor method has additional benefits over interpolation: 1.) Greatly mitigates the visible "hex-tearing" artifacts that occur when set to a fractional zoom value. (For reasons that aren't clear to me, it appears that the boundaries of hexes are not consistently being drawn / redrawn, or it may be that adjacent hexes don't talk to eachother to negotiate the boundary color, so that if A is redrawn and B isn't, the pixel is a different color from when B is redrawn and A isn't... note that this is speculation.) It is visible in the stills but they don't do it justice, the result is that when you scroll you get transient flashing lines all over at boundaries of hexes, especially around where lava or water hexes. With nearest neighbor, you still get some artifacts, but it is instead much smaller and sparser tiny dots that are not redrawn, and it is barely noticeable. 2.) Greatly reduces the lag time to recalculate cached images when zooming in a lot. Presumably this is because nearest neighbor is much faster than bilinear interpolation. So, since there *seems* at this time to be a consensus that the nearest neighbor results are preferable, and it appears to help with some other graphics issues, and it may indeed have been the original intent, I would like to treat this as a bug and fix it in 1.12, in time for RC3. Again, if there is not a consensus, please post back and I will drop the issue. Best Regards, Chris Beck On Tue, Oct 28, 2014 at 11:19 AM, mattsc000 <[email protected]> wrote: > Hi All, > > The good news: the file system problems with unicode characters in Windows > have been fixed by several people working together in a massive effort. > The (kind of) bad news: this is a huge amount of new code that did not make > it into the 1.11.18 release and has only been tested by a couple people so > far. > > We are not comfortable with putting this into an official release for the > first time in 1.12.0 and are adding one more release candidate, RC3, on or > about November 7. That means that tagging of 1.12.0 is now planned for > around November 14. The exact schedule will be set by Ivanovic when he is > back at the end of the week. > > On the plus side, this leaves us more time to work on the remaining > must-fix bugs, and also on a few "almost must-fix" bugs which otherwise > would have had to wait for 1.12.1. See list below and please let us know > if anything should be added to that. > > Cheers, > Matthias / mattsc > > > Remaining must-fix bugs: > > - Multiplayer start of scenario saves are broken (bug #22068). Nobody > currently knows how to fix this in 1.12. Fall-back option is to disable > SoS saves in multiplayer mode. (thunderstruck) > > - Legend of Wesmere: Olurf does not appear in “Elves’ Last Stand” (fendrin) > > - OS X release builds don't currently work in OS X Leopard (10.5) with the > new file system changes. (mattsc) > > > Other desirable bug fixes and actions (this includes some very minor > things this time): > > - AI side names in MP are all set to that of the host. (thunderstruck) > > - Add-ons Manager Filter box and Options button too close to listbox (bug > #22791). In the worst case this can be fixed by reverting one specific > commit (shadowm) > > - Give level information in sidebar more space (fendrin) > > - Verify if textdomain bug reported by Dugi is reproducible, and fix if it > is (volunteers?) > http://forums.wesnoth.org/viewtopic.php?f=12&t=41129 > > - Check out problems with 1.11.16 and later not working in Windows XP and > whether they can be fixed (loonycyborg) > http://forums.wesnoth.org/viewtopic.php?f=4&t=40835&hilit=windows+xp > > - Fix upkeep icon tooltip not being displayed (fendrin) > > - Complete play-through testing of LoW in both SP (mattsc) and MP (fendrin) > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
