If you load a "classical" format, you need to load six of them (plus mipmaps if applicable) and reassemble them into a cubemap at runtime. You also don't get the option of using a compression scheme supported by the GPU. So yes, DDS is the best option.

You generally shouldn't use regular image formats like TGA anyway.

TGA files take up a massive amount of disk space. JPEG files have lossy quality and no alpha support. PNG files do silly things with alpha=0 pixels. JPEG and PNG have to be decoded. None of them support mipmaps. None of them support GPU-compression.

On the other hand, game textures should support optional alpha values (without losing RGB information in alpha=0 areas), should support mipmaps, and should almost always be GPU-compressed.

If you use traditional image formats, this means that when you load them, you have to decompress them, generate mipmaps, recompress them to the GPU formats (e.g. DXT5/BC3, etc) and then load them into D3D/GL/etc... which is a huge waste of time.

Your game engine's tool set should let the artists author textures in whatever formats they like (such as TGA), and automatically convent the artist's files into game-ready files, such as compressed DDS format.

But also if we say that we also have to say : the build has to convert to another format, so the uncompressed has to be stored during the dev process.

True, the issue is if you store the compressed image then you have to decompress and compress again which is a kill on the quality.

I don't know why you would do that. When you're working on the game, you either export the correct format from Photoshop, or you use a conversion step in your build that assembles the files. Sometimes people will include the ability to load generic image formats in the engine as a quick/easy testing option. When the actual game is being packaged though, you would convert everything.

True, the issue is if you store the compressed image then you have to decompress and compress again which is a kill on the quality.

You don't "store" the compressed image. Artists work with the source image, which may be a Photoshop .PSD, and overwrite the game assets. In a normal pipeline you never uncompress the .DDS image except for diagnostic reasons, and this is still offline, and it does not affect the final quality. Additionally, compressing an image to a BC* format, decompressing it, and then compressing it back to the same BC* format should always result in the same exact image as the original compression. Once it is compressed the first time, that is the same result that any further decompressions/re-compressions should get. It doesn't degrade the quality each time.


L. Spiro

the question is really about import process. But also if we say that we also have to say : the build has to convert to another format, so the uncompressed has to be stored during the dev process.

So in my engine, everyone has the engine tools running on their dev PC. Artists work with files in the 'content' directory, the tool reads these files, and produces new files in the 'data' directory. The game only reads data from the data directory.
e.g.
artists ---> ./content/blah.png ---> engine tool ---> ./data/blah.dds ---> game
You can either run the tool in manual mode, where the user has to click on a 'Compile' button in order for the content files to be compiled into data files, or, they can run it in automatic mode, where the tools will subscribe to filesystem notification events so that every time you create/modify a file, the tool will automatically compile it into the data version in the background.
Artists don't have to know that the DDS files even exist. All they need to know is -- leave the tool running in automatic mode, or, if using manual mode then click the Compile button before launching the game.