Most OpenGL ES1.1 hardware doesn't have ST3C, although that may change as ES 2.0+ becomes common.

As a specific example, Apple and PowerVR both provide a wrapper format for PVRTC, and a toolchain to produce them. Although they use the same compression, the wrapper format is non-compatible, and supports slightly different features. The Apple tool runs only on Macs, while the PowerVR tool runs only on Linux and Windows.

Speed/quality isn't really an issue. However, I do wonder how people would feel about rolling this out of the engine entirely?

I am talking about building a Horde3D-specific (though the format would be open, of course) wrapper format, which can hold all types of compressed/uncompressed image data (uncompressed, RLE, JPEG, S3TC, PVRTC, ETC, etc.). There would be a tool that leveraged FreeImage (or similar) to convert/batch convert other image formats into the Horde format, which would move this whole issue out of the engine and into the content pipeline.

I have a feeling it is too big of a break from tradition to be well received - but it is the approach taken by the WildMagic engine.

FreeImage doesn't offer anything apart from .PSD support, over what we have already - and it doesn't have mipmap generation or DDS support, last I checked.

I have no particular need for it, since all my targets feature S3TC, so a software fallback is indifferent for my particular needs.

I have never used a Mac platform, nor developed for the iphone. I also was not aware that that they provided a PVRTC toolchain/wrapper, I hope it is possible to abstract the differences and use a unified set of functions to work with PVRTC textures.

I don't think i understand what you mean. Can you provide more details on how this woul work? what are the benefits and issues?

We have had a couple of requests for both ETC and PVRTC, so someone must need them.

it is possible to abstract, but it multiplies the code we have to maintain.

We strip all texture loading code out of the engine, and replace it with a custom format, specifically designed to contain any type of compressed/uncompressed image data.

Then we provide a tool that will use FreeImage (or whatever) to convert standard image formats into our custom format.

Pros: simplifies texture handling in engine, allows support of *any* format with minimal work and no complexity on the engine side, simplifies art pipeline for different device targets
Cons: requires separate tool - can no longer drop an image in and it works, you now have to convert the image first.

Hum... i don't get how it would simplify the art pipeline, i would still need to have a file for each platform, one compressed with pvrtc and one with s3tc...

But well that would make Core dependent on image upload functions. Smaller core & thicker shell VS bigger core & thinner shell.

IMHO core engine doesn't need to know about different formats

The core engine has to submit that data therefore it must know a good deal about it, unless you'd propose to write a single proprietary image format, which would be a bad idea, topping or even competing with most existing formats is an unrealistic goal (they each have their pros and cons).

At the same time, a solution for wider format support should also consider the fact that solely using XML for other resources is silly, at some point optimal binary archives for release builds would be ideal, especially in circumstances where streaming is a necessity, the same approach used for handling image after image should at its core be suitable for dealing with similar issues elsewhere.

We only need a very restricted set of formats - compressed/uncompressed, 1-4 channels, with/without mipmaps. That would be very easy to package into a custom container format, perhaps easier than abusing DDS to support other forms of compression.

Agreed. To my mind, the core engine should only know how to load binary data from memory, and the current XML resource manager should be factored out into a separate (optional) layer.