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.
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.