I don't think the info in that post was accurate, but maybe we're talking about different types of compression (pixel compression vs. file size compression). The phyre textures in CS1 and CS2 did use compressed DDS types: DXT1, DXT3, and DXT5. But the phyre file itself did not use any kind of file compression. The PKG format that contained the phyre files, did indeed use LZ77 compression, which was changed to LZ4 for CS3 and CS4. Some games also work with Zstandard compression, but it's not used by default in any of the games.
As for compression in these "multi-texture" phyre formats, I don't know why there is a table of alphanumeric values, but I'm almost positive they are not compressed in any way, pixel or file size compression. The DDS formats being used are uncompressed formats, ARGB4 and ARGB8, meaning the pixel bytes lines up exactly with what the data in each pixel contains. in ARGB4, exactly 2 bytes (16-bits) make up a pixel while in ARGB8, exactly 4 bytes (32 bits) make up a pixel. Knowing that, the format, and the dimensions, we can calculate exactly how many bytes the image will be. Which works up to a point, at least in the phyre image collection I was working on until I hit a brick wall. The "next" texture after I think texture 38, the bytes don't line up with either what ARGB4/ARGB8 "should" be.
Textures 38 and 39 (might) be correct, it's hard to tell. Textures 40 and beyond though are definitely corrupt. They look like some kind of bar, but there are pixels missing in them. It's possible there are more or less bytes, they could be grayscale, I don't know too much about uncompressed grayscale formats. They could use even less pixels. They could also be a weird format like L8/A8/LA8 meaning luminance/alpha textures. Maybe there are mipmap pixels in some textures, its possible, or maybe its a different format altogether. Or maybe its a mistake. It's hard to know without pointers.
Speaking of pointers. No this file does not contain any. If it did, this would have been solved within an hour. My current script prints out the first bytes of images that do work, so these values are correct. And these are nowhere in the file. For example, here is pointers for the first five textures in hex: 6210, 87D8, A1D8, A478, A9B8. These files tend to be little endian, so the first 2 and last 2 bytes are flipped: 1062, D887, D8A1, 78A4, B89A - these would be the pointer values of the first five textures. Unfortunately, the phyre file does not have these values anywhere.
I have also made it so the stride of each image is printed out, and unfortunately those values are nowhere either. If we knew how many bytes each image was, then we wouldn't need pointers. Those values as far as I can tell, are nowhere to be found either. Here is the first five stride values of the textures: 25C8, 1A00, 02A0, 0540, 06E4 and of course swapping the endianess: C825, 001A, A002, 4005, E406. These values are nowhere to be found either.
Here is the work I have put into it thus far:
https://www.mediafire.com/file/n5pg6x7xx...ff.7z/file
Just run the "TestScript" by right clicking the script and selecting "Run with Powershell". This will display some nonsense and extract some textures. They are in their native formats so they need to be converted to PNG to view them or use some kind of image viewer. Much of the values are hardcoded, so it's not useful for other files. I was hoping some kind of pattern would emerge, but quite the opposite: I imagine every file would need to be individually hardcoded with what we currently know about them.
This is the place where I manually swap formats depending on the index before hitting a brick wall. But even figuring out how to get beyond this point doesn't give us any clues on how to apply this to all of these files. It could be possible to build a script for each file, but that would be very tedious and a lot of trial and error.
Feel free to share this post with anyone who wants to take a crack at it. Maybe they can succeed where I have failed. The best solution would be one that can handle any of these files. Figuring out a single file is nice enough, but the process would need to be repeated for every single one. There is definitely something I'm missing. In that block of data just below the alphanumeric values, might hold the key to what that is. When I get some more time I'll look into it more, but at the moment I'm no further than I was a week ago.
, masagrator:
