Complicated Texture compression...

[Alhexx]

...that I've found here.

Okay, I'm currently (also) workin' on an ONI ripper, basing my work on a C Source. And I've found this one there:

Code: [Select]

/****** TXMP Format Info ******************************************************
 *
 * 0: AAAARRRRGGGGBBBB
 * 1: ARRRRRGGGGGBBBBB
 * 2: ARRRRRGGGGGBBBBB
 * 8: AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
 * 9: Compressed 4x4 block method
 * RRRRRGGGGGGBBBBB RRRRRGGGGGGBBBBB XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 * This method stores the texture as several 4x4 blocks. Each block starts
 * with two colors. Then follows 32 bits of pixel information. The pixel
 * block is laid out like this (two bits per pixel):
 *
 * 03 02 01 00
 * 07 06 05 04
 * 11 10 09 08
 * 15 14 13 12
 *
 * The first and second colors of the palette used to decode the block are
 * the first and second colors read for the block. The third and fourth
 * colors are the two colors in-between the first and second.
 *
 *****************************************************************************/


I understand type 0, 1, 2 and 8, but 9 ?`I have no idea how to decode that. If someone's interested to take a look at the Source,here it is.

Please help me ... if you can ... I'm so depressed ...

 - Alhexx

[ficedula]

I believe this is a job for ... uber-Ficedula!

Well, maybe just normal me. But anyway...

This is a lossy but simple method of texture compression. I *think* it looks very similar to S3TC, but I'm not sure (I've never had to actually deal with data in S3TC format of course, I always let the video card handle that for me).

Anyway. Format 9. Each "block" of data is 64 bits (8 bytes long), and defines 16 pixels, which is very efficient. Essentially it uses a tiny palette, and to save even more space, half the palette is just interpolated colours.

First 2 bytes of data give you colour 0 in the palette, stored in 5-6-5 format.

Next 2 bytes give your colour 1 in the palette, again in 5-6-5 format.

What about colours 2 and 3? Interpolate them. Colour 2 would be 1/3 of the way in between Col0/Col3, colour 3 would be 2/3 of the way in between.

Then you have 32 bits of data (4 bytes) giving the actual pixel data. Each pixel has 2 bits which - surprise! - is the index into the 4 colour palette you've just built. 16 pixels takes up the full 32 bits of remaining data.

The 4x4 matrix you've specified shows what order the pixels are stored in. The data seems reversed horizontally because of Intel byte ordering, I presume.

Does that explain it ... or not? (Didn't seem *that* hard to me, but then, I'm used to working from incomplete specs ... our hardware department is a great one for that...)

[Alhexx]

Oh, Fice, what would I do w/o you? I guess nothing - no opengl, no ultima, and now, no Oni ripper.

Well,



 - Alhexx

[Alhexx]

Fice, with your help, and after some hours trying around I've finally been able to decode the textures. So, like I said above, Thanx

 - Alhexx

 -  edit -
I just hope I will be as useful for the next generations as you (and others like mirex and SaiNt)
[edited] 169 2001-11-28 20:32

[ficedula]

Heh, np

[Alhexx]

Well, no compression this time, but an encryption, just take a look at it:


Does this remind you of anything? If yes, or if you know how to decode this mess, please tell me...

 - Alhexx

 - edit -
corrected BBcode...
[edited] 169 2002-03-04 16:24

[ficedula]

Reminds me a lot of the FF7 tile data for the backgrounds - each small 16x16 block (or whatever the size is here) made sense, but you had to rearrange them all over the place to get a proper picture out of it...

[Alhexx]

Yes, that's exactly what I've seen. This is a Parasite Eve Background file. What I wanted to know is if anybody has tried to decode the FF Backgrounds...

The problem is that every background seems to have its own 'key' with which it is 'encrypted'... hm... let's take a look at Qhimm's sources... :naughty:

 - Alhexx

[Renderman23]

Well anyhow im looking through my dabblings right now, and Im finding alot of cool things. << be nice Im new to this.
Whats a .rsd file?   i see string data refrences to it in the decompiled exe, but nothing in browsing of the files.
Also, i found some sections that have stringed comments, C:libsrcpolygonplytopd.cpp
Poly to pd? also found some that had to do with textures..
psxtossi or something ,, ill prolly just go thru and list all the strings found thus far... Oh and btw... let me know if im messing up < Still sketchy on whats legit in trying to decompile for whatever pourpose.

[Qhimm]

Alhexx: Encryption is a very poor word for this. The content has in no way been scrambled to prevent the contents from being viewed, it's simply stored in the most efficient way for the game engine. The mapping for each field background should be stored within the file.

Renderman: RSD is a standard PSX model format (sort of). FF7PC uses a "compiled" version of RSD for its models. The .rsd files are "index files", telling where the model data can be found. These strings in FF7.exe are remnants from the debug version, they are used with debug messages, telling in which source file and on which line the trace originated. Unfortunately, they are pretty much useless when it comes to figuring out file formats and stuff.

As a rule, decompilation of commercial programs is a no-no. If you plan on decompiling FF7, do not talk about it in this forum.

[dagsverre]

Last time I checked, disassembling programs was protected by law in EU for educational purposes. Don't take everything Microsoft tells you for granted...

Agreeing with your decision to disallow it on this board though.

[Alhexx]

The problem is that the picture has no header or things like that. It is just raw pixel data...

BTW: Tadaa!! this is the 17.000 Post !

 - Alhexx

[Qhimm]

dagsverre: Well that's just cool. It *should* be that way, but you never know...