While the BC1-BC3 transforms were fairly simple and straight forward, formats like BC6h and BC7
massively increase complexity. Experimenting with different ways to transform them takes a lot of
time.
To help with those formats, any many others, I built a tool for defining and comparing transforms.
In my previous post in the series, I've demonstrated a recipe for making BC1-BC3 texture data more
compressible, ~10% saving at a blazing ~60GB/s on the single thread.
That transform is usually beneficial, but there will be rare cases where it isn't.
With more complex files, such as files with multiple distinct sections, you may want to apply
transforms on a per section basis. Or even skip individual steps of a transform.
But how do we know if a transform is beneficial or not?
Hooking NT / POSIX API calls to trick processes into reading files from another place.
Except we're reading from an archive.
If we load/decompress on all threads, we load data faster, using less disk space.
File Downloads: Mods need fast file downloads.
Support streaming/partial download of archive contents.
Minimize file size.
User downloads less, mod site needs less traffic.
Everyone is happy.
As a game archive format: Replace old games' native archives with the new format.
Through hooking, we can replace a native archive format with our own.
For size, performance, and just because you can.
Medium Term Archival: I want to save some mods on disk for future use.
Basically as a general purpose archive format.
For non-Reloaded3 software, to archive currently disabled mods to save disk space.
The archive format extracts data so fast, extraction is as fast as your storage drive.
So like 8GiB/s on a modern NVMe.
The last one, mainly to seek adoption.
Today, we're going to be unraveling one of the tricks to achieve one of these goals;
faster texture loads and smaller sizes via texture transformation.
I'll speedrun you through the basics of the simplest (BC1 / DXT1) transform, and how you can
write similar transforms to improve compression ratios of known data.
I'll keep it simple, no prior compression theory/experience required.