My new engine editor allows me to tweak my textures' properties such as filtering, wrap modes, max size on a per-platform basis so my artists can make high-res textures, optional mipmap generation, etc... I will also allow the user determine which format the texture data will be stored as (32-bit RGBA, 16-bit RGBA_5551/RGB_565, 8-bit alpha, etc, PVRTC 2/4-bit via provided compress tools, etc). Then, I'll write its properties and its pixel data to my own custom texture format. The textures are loaded in-editor using the FreeImage library. Would this be a good way to go about it, or should I consider compression encoding non-PRVTC textures? This would require extra data pools to stream in temporary compressed data so it can be uncompressed leading to longer load times than a single freed(). Textures can get big quickly, for example: a single 1024x1024 texture takes up 4MB of disk space if stored uncompressed plus its small header data. I could get around that by putting all my files into zip archives. Does a custom file format sound like a good idea?
My texture system extends beyond typical 2D textures as well. For example, I'll have a cube-map editor that'll put all my cube maps together into a single "atlas" of sorts. I'll also have a 3D texture editor and 1D texture support. The idea is that the data is serialized into file formats that my engine can readily load up quickly with only a handful of fread() calls. They're large cuz I'm banking on uncompressed texture support (except for PVRTC), but possible. Of course, loading zips from an APK on Android will prove annoying as I'll have to copy all of my zips from the APK (which is a zip archive) into a cached directory.