Does Mali's Astc encoder scan textures from top-to-bottom or from bottom-to-top.
When decoding Astc textures, it appears to be bottom-to-top, but a Microsoft document indicates that it is top-to-bottom.
Adaptive Scalable Texture Compression (Preliminary)
Thanks,
Doug
in the previous response i forgot to mention that i am using a 6x6 footprint
Do you still stand by your assertion that astc's scan order is top-to-bottom?
Ah, sorry - I misunderstood your original question - I was talking about the UV coordinate expectations from the application point of view when addressing into the textures from shader code (which is also what the Microsoft article is talking about, as far as I can tell).
The internal layout of compressed blocks, and the addressing from the application point of view are somewhat orthogonal (hence the same compressed texture can be decompressed differently on DirectX and OpenGL ES because the expectations of the UV addressing are different).
This basically all comes down to how do you define "top" and "bottom" - the original storage format on the host (origin may be top or bottom depending on data format), compression (origin is top left), and decompression (origin may be top or bottom depending on API) are all variables. It's entirely possible to have a texture which is "correct" for OpenGL which will be "upside down" for DirectX ...
HTH,Pete