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

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.

—

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

dont want it .stick with the 'medium' option.

a big thank you to ashley for working hard and finding solutions to our problems.

And the 4th option would be to use newt.angle.

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.

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.

Hate to say this, but would not using a spritesheet solve the problem as well?

Ashley - Right, that makes sense. One more question, if you don't mind - I wonder if there's a way to generate mipmaps by isolating each animation frame to its own texture when creating the mipmaps (by either cropping the rest off or copying/pasting that singular animation frame to a new texture, then resizing it, then pasting it back to the spritesheet)? Then it wouldn't average pixels from adjacent images because there wouldn't be any.

Since the problem only happens on export, and sprite sheets only happen on export, having the textures isolated solves the issue, so I'm basically wondering if you can make that isolating behavior happen from a spritesheet at mipmap generation time.

Or, as newt said, perhaps giving us an option to turn sprite sheets off would be optimal for some users? Or would that essentially make no difference by resulting in the same amount of memory used as putting them all in power of 2 locations? I guess if that's the case then the only difference would be more file requests which is a disadvantage.

Turning off spritesheets can increase the download size and could disable mipmaps unless they were still padded out to power-of-two sizes (since mipmaps are only supported on power-of-two textures), so it doesn't save memory or results in quality degradation equivalent to turning off mipmaps.

I think it is possible to custom-generate mipmaps which are correctly filtered according to the spritesheet, but doing that kind of logic in JS can considerably increase the startup time, since JS isn't always the best at heavy data processing. Right now we just use glGenerateMipmap which does it automatically in the driver.

Hmm... Maybe it could be an option to generate the mipmaps when exporting the game from C2? It would increase the download size (I've read mipmaps add 33%, don't know if that's correct or not) but improve startup times, and large games are quite common these days so 33% more image data might not matter for some users (for example, those making a downloadable exe, and the current fix increases download size too). My point is I think it's better to increase the download size rather than the memory use.

Also, does C2 generate mipmaps when previewing?