Add LoadFromDDSStream{,Ex}()

[solbjorn]

Many games support own archive formats and implement own sort of a virtual file system. In that case, LoadFromDDSFile() doesn't fit, while LoadFromDDSMemory() requires 2x filesize: one buffer to read the file and another one to load the texture, since ScratchImage is always owning.

Add a simple InputStream class and LoadDDSFromStream() to avoid this memory overhead and allow games and apps to use their own functionality to operate with files or memory.
More formats could support this in future, as well as writing to an OutputStream if/when needed.

[solbjorn]

@microsoft-github-policy-service agree

[walbourn]

For loading DDS content at runtime in a game, I'd suggest not using DirectXTex or at least not the library. It's designed to load and convert all kinds of legacy content to modern formats, so it brings a lot of code to bear.

The DDSTextureLoader module is intended to be more light-weight and focused on the needs of runtime. That may be a good place to look at adding the Stream version instead.

[solbjorn]

We considered using DDSTextureLoader, but unfortunately it's a poor fit for our engine, probably not only ours. We don't want our texture loader to require a Dx context or to create SRVs/UAVs/whatever for us. Once we have a list of textures to load, we load them and create ID3DBaseTexture (using CreateTextureEx()) on as many threads as possible and that's it. Later, we create the associated resources before the first usage. Using DDSTextureLoader would limit this to 8 threads or even to 1 if a deferred context can't be used to do this.
When using DXT1/5 or BC6H/7 (99% of our textures), LoadFromDDS*() is pretty straightforward: it parses the header and then reads the texture directly to the buffer that ScratchImage allocated and that's it.