Seriously:
Totally not happy at all about the introduced texture size limit of 1K on Tegra 2 in the latest patch. Textures above 1K simply don’t draw at all and cause black materials on Tegra 2 ?
Seriously ?
I’m in the finalize stage of a larger project tartgeting Android and yes Tegra 2 too
I never had any troubles on my TF101 Tegra 2 device and currently use 2K textures which bring a clear visual quality boost and performance is great too. And now you simply don’t draw any textures >1K on Tegra 2 ? 
I understand that you are in a tight situation currently , regarding all the no more browser plugin and Apple requiring 64 bit builds etc…
But taking such a shortcut and simply cut of Tegra 2 support in that way is simply too much
Now i should not have a chance for Android fixes any longer if i want to support 2K textures and still target Tegra 2 devices?
At least introduce a global #DEFINE to override that limit
I’m pretty pissed because of that currently … seriously
PS:
i’m aware that Unity 5 does’nt support Tegra 2 at all any longer . This is even MORE a good reason to NOT leave the final 4.x version with such a shortcut in it
SO PLEASE:
introduce a #define to override that 1K texture limit on Tegra, or any other means to not get black textures if i have 2K textures and run on Tegra 2 …
I just learned that i get black materials on Tegra 2 because the new texture limiter falls back to 1K sized mimap levels on Tegra 2. ( which are disabled in my project on those specific textures for reason). It seems to me that the whole implementation has not been thought through enough:
What are people gonna to when they make use of hires sprite sheets for game sprites or UI elements for the new shiny Unity UI ? Sprites to not have any mipmaps at all ( like in my case ) - So the people simply should forget Tegra 2 devices ?
Best thing, most propably they will never know that people on Tegra 2 get black materials or black sreens, if they do not test on Tegra 2. And just because there are some driver problems on some Tegra 2 devices ?
Please seriously rethink this texture limit:
it causes far more hazzle and confusion than it helps !
Well, it sucks, but it doesn’t mean you don’t have any other choices.
Multiple apks: Unterstützung für mehrere APKs | Android Developers
If you really want to support Tegra2… but I don’t understand why they dont want to support it anymore
Yes thanks - multiple APK would be the final solution
But it introduces even more deployment complexity- I’m already juggling with iOS/Android/Windows/Web and Desktop exports
And as you said: i believe they took a shortcut because of some customer reports
But throwing the whole Tegra 2 support over board because of that is’nt a solution
It just shows that making decisions based on some internet hardware statistics is’nt a solution. I guess their own HW stats gave them reason to think nobody would use Tegra 2 any more …
Well, about complexity, I believe you have 2 options, where 1 is really complex while the next solution is easy.
- The easy option would be to override the texture size for Android to be 1k, though you will loose some quality on your graphics. But it’s easy, you don’t have to do anything else.
- Difficult way, is to re-create the atlas texture with 1k size on mind. It will require some more optimizations, means the amount of draw calls will rise, and etc etc. But the quality of graphics will be the same.
I know that there are solutions - but they are suboptimal. Overriding texture sizes for Android in general would mean clamping the visual quality even on the most modern Android HW, and thats definitly not a route i will take.
Generally speaking:
I don’t really see the urgent need for Unity too enforce that texture limit on the whole Unity 4.x branch that late in the game, just because there seem to be driver bugs on Tegra 2. As i mentioned above, i never had seen any troubles with >1K textures on my Tegra 2 devices.
Unity should just give us a way to overrule that Tegra 2 autolimiting on export. Simply as that …
We are rolling this change back in 4.6.1p3, until a better solution is found.
Thanks for that …
I prefer that solution 