В настоящее время я пытаюсь понять / перепроектировать формат файла текстуры игры, которая должна быть прекращена, чтобы «спасти» как можно больше данных, прежде чем она будет закрыта.
Файл текстуры на самом деле является контейнерным форматом с заголовком, а затем данными для каждого уровня mip множества различных возможных форматов. Заголовок указывает, какой из 27 возможных форматов используется в файле. Большинство из них довольно просты (обычный DXTn, несжатый ARGB, одноканальный, текстуры куба, ...), но у меня возникли проблемы с первым возможным форматом, и мне было интересно, может быть, кто-нибудь знает алгоритм, который мог бы ему соответствовать.
Используя Intel GPA, я смог выяснить, что эти текстуры заканчиваются как DXT5 (BC3_UNORM), поэтому я предполагаю, что использует сжатие поверх DXT5 в файле, так как кажется маловероятным, что его unknown format -> ARGB -> DXT5 .
Другие вещи, которые я сейчас на данный момент:
- Сжатие не имеет фиксированной скорости, текстуры одного размера имеют существенно разные размеры файлов
- В заголовке имеются дополнительные поля, присутствующие только в том случае, если используется этот формат. Один, по-видимому, является повторением числа уровней mip, другой - это 4 3-байтовые значения, часто это следующий шаблон:
4B 00 00 4B 00 00 4B 00 00 4B 00 00, а другой часто встречающийся шаблон - 5C 00 00 5C 00 00 4B 00 00 4B 00 00
- Кажется, что слой mip 1x1 всегда имеет размер 6 байтов (дополненный
0xFF для заполнения 16 байтов)
- На изображениях 1x1 нет общего префикса, поэтому они имеют совершенно разные значения
Я подумал, что, возможно, это может быть использование crunch over DXT5, однако я не уверен, достаточно ли дополнительных 5 32-битных значений в заголовке для этого формата или как будет выглядеть сжатая информация.
Кто-нибудь может распознавать шаблоны сверху по определенному алгоритму?