Hey!
I believe the distance-based texture quality thing you're talking about could be done with mipmapping with distance-based level of detail (LOD) texture fetching.
I believe jPCT has support for mipmapping but I've found it a little buggy for myself... (Or I'm just not sure how to make use of it properly)
I'm not sure if default shaders use this...
I believe for this technique, you should take into account that twice the memory consumption of the base texture is necessary. (With a peak of 4 times the memory consumption of a single base texture with default jPCT texture loading (I'm not entirely sure about this, however)).
LOD | Resolution |
Level 0 (base) | 8x * 4x |
Level 1 | 4x * 2x |
Level 2 | 2x * 1x |
Level 3 | 1x * 0.5x |
Level 4 | etc... |
with x being some resolution scaling factor...
I believe if your texture loading 'algorithm' is efficiënt you could probably get away with loading textures at at a maximum peak memory consumption of just twice the base texture memory consumption.
The memory consumption of a single texture can be calculated approximately as follows:(
https://www.jpct.net/wiki/index.php/Reducing_memory_usage)
Remember: 8 bits = 1 byte
Higher color quality:
For 32-bit: width * height * 4 bytes
For 24-bit: width * height * 3 bytes (no alpha)
Lower color quality:
For 16-bit: width * height * 2 bytes
For 12-bit: width * height * 1.5 bytes (no alpha)
So for example:
Let's say you have a 32-bit texture of 8192 by 4096 pixels.
The memory consumption can be calculated with the above formula.
This would result in approximately 130 MB.
When doing mipmapping, the memory consumption will be nearly doubled, so that'd be 260MB.
I believe that with jPCT's default texture loading algorithm, it'd be doubled in peak memory consumption for both scenarios.
260 MB without mipmapping, 520 MB with mipmapping.
Maybe something else that could be useful:
https://www.jpct.net/forum2/index.php/topic,5135.0.htmlI guess it could be extended to allow for more efficient texture loading and also mipmapping... Mind that Android makes a distinction between loading textures to (J)VM memory and native memory, where the first is usually more limited...
Hope this was useful in some way!