get_array_stride sometimes incorrectly assumes that mip levels have byte-size 1/4 of the previous level #5
Description
That assumption is not always true when using block compression. Most cases are correctly handled via the "min_mipmap_size" param, but there are a few cases where this won't work:
For example, a 16x4 texture uses four 4x4 blocks and takes up 4xblock_size bytes. The next mip level is 8x2 pixels, which uses two blocks, so it takes up 2xblock_size bytes, so only half of the size instead of 1/4. But since the "min_mipmap_size" value is just 1*block_size, this gives an incorrect result.
It works fine for e.g. 8x4 textures thanks to the minimum block size. I only noticed this today after switching to a more space-efficient texture/rect packer that manages to end up with a 4096x1024 texture instead of the previous "textures are all over the place in my texture atlas so that atlas texture is a full 4096x4096 square". :-)
So the calculation needs to take dimensions into account. I'll try to fix it and send a PR, but I can only test using the unit tests and what my own app does, so it might break other stuff.