What is Small VQ compression?

This isn't something I'll do, but its an interesting idea on having even smaller textures work on the DC:

The hardware determines that the texture address specified in the Texture Control Word (TCW) (textureformat from texconv's Dtex files) is the start of the code book data, and uses the address produced by adding 256 x 64-bits or 2KB to that address as the start of the index data. Therefore, in order to have a code book with less than 256 elements in its code-book, use an address in the middle of the previous texture data as the texture address that is specified in the TCW, and then store index data only for the values that correspond to the code book data that was stored.

So to be clear, we have a binary with a list of texture_data_offsets, heights, widths, everything related to textures. We allocate space for the texture and load it in. Calculate all the TCWs based on the binary's address and the texture_data_offsets. The first texture will have its TCW equal to the binary's address, the second will be binary's address - texture_data_offset[0] and for the next texture its binary's address - texture_data_offset[1] etc. Make sure when you allocate space for the binary that you move it into later/larger-value addresses since we can't have negative addresses and putting it into low-value addresses could cause you to reference negative addresses

To summarise, it seems "Small VQ compressed textures" is what happens when you use the "texture-address-offset" hack/trick used for getting smaller code-block tables to combine multiple small compressed textures into one "texture". This weird multi-texture would have to be made at compile time and is loaded in as one texture

This also allows multiple texture's to share some code-block entries. For example texture, "4" also has access to code-blocks for texture 5, 6 and 7 since its a part of its "256 entry code block"