Dicing and Android Texture Formats

[sstublic]

Let me start by saying I really love 2DToolkit and the level of support you're providing. Very professional!
I'm recommending your product to anyone who asks.
I hope your UI will be done in time for my next project, because I'm definitely switching

Questions/issues:

1. Dicing
I've been trying to use dicing on my sprites to maybe try to reduce some atlases a bit.
a) What exactly do numbers Dice X and Dice Y mean? Default has Y set to 0. I browsed forum and docs a bit, but couldn't find clarifications
b) When I dice my sprites, at some zoom level I start getting artifacts (black lines separating quads in the sprite) and this makes dicing unusable in my product ATM. Is there any way around this? I had similar issues with tilemap, but setting padding extend to 4 pixels solved it. How can I solve this for dicing?

2. Sprite transparency/texture compression
I'm kinda new to mobile development and recently I got boggled down in texture compression formats. Turns out that only compression widely supported on Android devices is ETC1. However ETC1 doesn't support Alpha channel. This is a big problem for using sprites, because ALL my sprites use transparency (I could get away with only fully transparent or fully opaque pixels).
This makes RGBA16 more or less the only viable texture format for Android and it eats up ton of memory since I use a lot of animated sprites.
Is there a way around this? Is there some automatic way for tk2d to handle workaround for ETC1 textures? (I read about 2 separate textures; one containing sprite and one containing alpha)
Is it possible to have a shader which would make only pure black or pure white pixels transparent? This would work for those who don't need partial transparency.
Any other generic suggestions on ways to handle this?


Thanks,
Sasa


p.s.
We have been using 2DToolkit for our main game engine and I'll post our Beta in Showcase soon

[unikronsoftware]

1. Dicing - as you know it dices up the image into tiles. X & Y refer to the tile size it gets chopped up into. A dice value of 0 means full size in that dimension. So x = 64, Y = 0 will split the image up into 64 pixel wide strips running all the way from the top to the bottom of the image. You only get artefacts when zooming out. This is unfortunately due to the nature of dicing. You can increase padding to help, but there are no guarantees it'll work. Also, if you turn off mipmaps it might help.

2. There isn't an automatic workflow for 2 textures (RGB, A) at the moment. Most people using 2D Toolkit have been using either uncompressed or 16 bit dithered textures that this is the first time this has been requested actually. It is certainly possible to do it as a post process to the sprite collection build process. I can point to where you'd do it if you're interested in implementing it yourself. The shader change should be fairly starightforward too.

[sstublic]

1. Which padding setting will actually affect individual diced quads?

2. Ok, I understand. I won't fiddle with it for now if I can avoid it. How about that other suggestion I had. Does it make any sense? Is it possible to simplify this transparency issue if only 0 or 1 alpha is present by making a SINGLE color fully transparent and making a shader for it?
For example, sprite will be drawn fully opaque, except for pixels which are pure black. For this method 1 RGB texture would suffice

Thanks

[unikronsoftware]

1. All of them will affect it. In this case its probably best to use "Extra padding" on the sprite itself.

2. That will work, but only if you don't have filtering enabled. As soon as you enable filtering your black / white color key will be nicely blended and you'll get a hideous outline close to the cutout outline itself.

[sstublic]

Ah I see...so it's basically a dirty workaround and should't be done like that

Thanks for useful info!

[unikronsoftware]

Not a dirty workaround, but one that will only work in certain circumstances. You don't want to use it as a general solution but there are certainly cases where it'll work.

[coshea]

Sorry to bring up an old thread, but didn't want to start one on the same topic (texture formats).

I've been looking into this too, as would like to try sprites that have compression on android. I'm surprised more people aren't asking here as many android devs making 2d games. Could be another good selling point to go on your feature list to get people to buy tk2d?

Anyway, found these links:

http://answers.unity3d.com/questions/139359/displaying-2d-graphics-sprites-on-android-with-etc.html
http://answers.unity3d.com/questions/45955/combine-two-etc-textures-with-custom-shader-one-wi.html

also here...
http://tocaboca.com/2014/03/toca-pet-doctor-the-story/
"But the thing I’m most proud of was our texture compression solution, where we packed pieces of the animals into atlases to save space and separated the RGB & Alpha information into separate textures, to allow for transparency even with ETC on Android, plus the benefit of higher visual fidelity on iOS"

The thing is, I guess you'd have to make an alpha image for each spritesheet at the different sizes 1x 2x 4x etc based on the pixels of the sprites. How hard would that be to do?