Pixel-width lines on image edges in Node-webkit export

Bugs will be moved here once resolved.

Post » Fri May 02, 2014 7:19 pm

@sqiddster , @ashley

if you remove the backspace graphic from the spritesheet (just under the joystick graphic) the problem is gone, so it has something to do with that, the more you go to minimal scale (browserwindow) the obvious the problem is on all of them.

i also thought because there's so much transparent area that this couldn't happen, but i actually doesn't matter, because its the other graphic on the atlas thats bleeding into the transparent area of the joystick, my guess is that the space between the backspace button and the transparent area of the joystick is not enough, this is a case where more padding between graphics on the atlas could be helpfull. you maybe could fix it here by using more transparent area around the backspace graphic.

ps: if you dont scale the window its not visible
ImageImage
B
70
S
21
G
7
Posts: 827
Reputation: 10,052

Post » Fri May 02, 2014 7:26 pm

same here, If I don't resize nw window lines are not visible.
Node-Webkit freezes, now this, something really wrong is happening either with NW itself or C2 export.
ImageImageImageImage
B
157
S
66
G
42
Posts: 2,603
Reputation: 35,343

Post » Fri May 02, 2014 8:47 pm

Just moved my monitor into a different position, and now there are lines under 3 of the last 5.
Image ImageImage
B
169
S
50
G
173
Posts: 8,319
Reputation: 110,282

Post » Fri May 02, 2014 9:34 pm

@newt hahahaha
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,689

Post » Thu May 08, 2014 5:05 pm

OK, I managed to isolate this to the mipmap. By default mipmaps are enabled and are used for high-quality downscaling. (This pre-processes high-quality resized images at 1/2 size, 1/4 size, 1/8 size etc. down to 1px). Unfortunately this works badly with spritesheeting: as the mipmaps get smaller, they blend more and more and cause bleed between unrelated images.

One possible fix is to disable mipmapping - but this reduces the downsampling quality, even with linear sampling. See this example (which includes the glitch bug with mipmaps, but notice the quality difference):

Image

The correct fix is to pad images to a power-of-two size in the sprite sheet, and ensure they are aligned to power-of-two positions. Then since the mipmaps scale down by a factor of 2 every time, the images don't bleed at low mip levels. I tested this and it fixes the problem. However it comes with a high price: it effectively defeats the memory savings from sprite sheets, and in many cases can force animations that used to fit neatly on to one sprite sheet to spread over on to two or three sprite sheets. This could double image memory usage for some projects.

I think the best solution is to make an option in the editor. I'll add a 'Downscaling' property with three modes:

Low quality: mipmaps disabled, dense spritesheets
Medium quality (same as happens now): mipmaps enabled, dense spritesheets (minor glitches such as the one reported here are possible, but appear to be rare)
High quality: mipmaps enabled, sparse spritesheets (should never glitch)

Hopefully it's not too confusing an option to introduce, but I want to avoid either degrading the display quality, or increasing memory usage significantly for a relatively rare problem.
Scirra Founder
B
397
S
236
G
88
Posts: 24,422
Reputation: 194,558

Post » Thu May 08, 2014 7:00 pm

Wooo! Thanks Ashley, much appreciated.

Would this option occur on a project scale or on an individual image scale? It only happens to a few images in the game, and I feel like a dramatically increased spritesheet size for every single animation could be a big sacrifice.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,689

Post » Thu May 08, 2014 7:04 pm

@squidster
i understand what you are saying but if he gives us the option to choose it is a win win situation.
power to the people!
you want it?you use it :D
dont want it .stick with the 'medium' option.
a big thank you to ashley for working hard and finding solutions to our problems.
B
15
S
6
G
4
Posts: 277
Reputation: 3,948

Post » Thu May 08, 2014 8:24 pm

And the 4th option would be to use newt.angle.
Image ImageImage
B
169
S
50
G
173
Posts: 8,319
Reputation: 110,282

Post » Sat May 10, 2014 12:30 am

@Ashley - I assume it's already been considered, but I'm curious for technical reasons, why doesn't an extra few pixels width invisible border added between textures on a spritesheet solve the problem? Why does it need to go all the way up to power of two padding and waste so much space? I realize 1 pixel wouldn't work because it's averaging the space from multiple pixels.
Moderator
B
95
S
34
G
33
Posts: 3,006
Reputation: 27,874

Post » Sat May 10, 2014 12:50 pm

@Arima - it doesn't really fix the problem, it just postpones it maybe to the next mip level. The way mipmaps work is they keep halving the texture size, meaning the area of averaged pixels doubles in a power of two sequence (so the first mip level averages 2x2, the next averages 2x2 areas so it effectively averages 4x4, the next averages 4x4 areas so it effectively averages 8x8, then 16x16, 32x32 etc). So the only way to guarantee absolutely that images never bleed across mip levels is to power-of-two align them again.
Scirra Founder
B
397
S
236
G
88
Posts: 24,422
Reputation: 194,558

PreviousNext

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 3 guests