i extracted some of the textures from outbreak they were in .sld format which was just a renamed version of a tim2
however there is some damn compression plz someone help me with this
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
RE outbreak textures
RE outbreak textures
You do not have the required permissions to view the files attached to this post.
i dunno which of these is the usefull one so i packed all files up that could be it
anyway thnx for trying to help me
http://tjbp.net/upload/obstuff.zip
EDIT:
i talked with alera, he thinks its a simple RLE compression
anyway thnx for trying to help me
http://tjbp.net/upload/obstuff.zip
EDIT:
i talked with alera, he thinks its a simple RLE compression
- alera
- advanced
- Posts: 71
- Joined: Fri Oct 06, 2006 2:33 am
- Has thanked: 14 times
- Been thanked: 5 times
Although the file may not be stricty RLE it does indeed use the technique.
during compression it identifies runs larger than 4 bytes(?) and compreses them into 2 or 4 byte instructions that basicaly fetch the data from a sliding window. I still don't understand it completly but I am positive it works this way, the instructions is what I don't understand. I cna barely fit it in my head and eventualy sometimes it fails when I try to uncompress small blocks manualy to see if I can understand it.
Every 32 bytes is the end of a block and inside this blocks is the instructions encoded as something similar to literal index(first byte) and runlength(second byte) there seems to be more data encoded in the 2 byte intstruction.
instructions look similar and can be put togheter, I can't figure out with precision how does the decompresor tels what is an instructions and what is data.
the instructions had a maximum runlength(I don't remember how much) so it is normal to see things like fetch[2]run[8]fetch[2]run[8] that explains the runs you mentioned. the minumum literal was like 4 bytes and it then copied those 4 bytes for the run length.
Attached is a picture that if I remember correctly is the compresseed and uncompressed version, one in sld and the other one in dds format so only the data is the same and not the header(forgot the size of the dds header).
BTW the compression achieved is negletable, hence why most files are similar in size to the could be uncompressed version(say always near 65k 16, 32k in size)
I managed to manualy decompress some blocks with my used to be knowledge :P but aparently I dind't writ eit down.. omg I cna't type
BeesWax: Ignore the file I sent you, data there is incorrect.
during compression it identifies runs larger than 4 bytes(?) and compreses them into 2 or 4 byte instructions that basicaly fetch the data from a sliding window. I still don't understand it completly but I am positive it works this way, the instructions is what I don't understand. I cna barely fit it in my head and eventualy sometimes it fails when I try to uncompress small blocks manualy to see if I can understand it.
Every 32 bytes is the end of a block and inside this blocks is the instructions encoded as something similar to literal index(first byte) and runlength(second byte) there seems to be more data encoded in the 2 byte intstruction.
instructions look similar and can be put togheter, I can't figure out with precision how does the decompresor tels what is an instructions and what is data.
the instructions had a maximum runlength(I don't remember how much) so it is normal to see things like fetch[2]run[8]fetch[2]run[8] that explains the runs you mentioned. the minumum literal was like 4 bytes and it then copied those 4 bytes for the run length.
Attached is a picture that if I remember correctly is the compresseed and uncompressed version, one in sld and the other one in dds format so only the data is the same and not the header(forgot the size of the dds header).
BTW the compression achieved is negletable, hence why most files are similar in size to the could be uncompressed version(say always near 65k 16, 32k in size)
I managed to manualy decompress some blocks with my used to be knowledge :P but aparently I dind't writ eit down.. omg I cna't type
BeesWax: Ignore the file I sent you, data there is incorrect.
You do not have the required permissions to view the files attached to this post.
- alera
- advanced
- Posts: 71
- Joined: Fri Oct 06, 2006 2:33 am
- Has thanked: 14 times
- Been thanked: 5 times
Yes it does, all files start with that or 44h I believe :) found some notes:
***************************************
Compressed picture
4104 5449 4D32 0400 0100 0000 0118 3004
UKID ITVL
0100 0004 0510 0100 3000 0001 0001 0305
ITVL
UK = Unknown
ID = counter?
LTR? = Literal? char to copy?(2 bytes)
IT = Instruction
VL = Value(num times)
Value seems to be 8 bits(shift 3 bits)
11111000
1 = repeat count
0 = unk (flags?)
The IT(Instruction):
The it has the number of spaces to go back in the first 5 bits
count 2 bytes before that position to get the literal to copy for the run.
flags(last 3 bits) are still unknown.
if there is no count in the literal or the value then delete and do nothing.
maybe the literal must also exceed the 32 bytes(or 12) or something.
- Spacing is 32 bytes(maximum length of compressed output.)
*************************************
ROLF and don't ask me what it mean! I can't understand what I wrote and is probably incorrect as I write what I discover as I go. the file I recovered from a dead file system and could not retrieve the time stamp so I don't know if it is the latest >.<
Just remembered: that data is wrong, back then I though there where 2 types of data one that was UKID and the ITVL but they are actualy both the same ITVL - instruction and value(2 bytes) is just I didn;t understand the part with the header.
Edit:
At 0x54 in yokotex1.sld and 0xCC in the uncompressed file
Compressed:
0208 080F 0600 1318 0101 0118 0303 0103 0210
ITVL = 1318, 0118, 0210
1318: don't get it but has a run of 3
0118: go back 1(2 byte pairs, first entry in index?) repeat 3 times
01 index number
18 = 00011000 shifting to the right 3 times gives us 00000011(3)
0210: select 4 bytes as the literal... ? copy 2 times
the uncompressed file shows this:
0208 080F 0600 0000 0000 0000 0101 0101
0101 0101 0303 0103 0303 0103
it is pretty close :)
IT must be 4 bits long since it uses pairs of 2, if it was 5 bits the IT will be able to go before the begining of the block that is 32 bytes.
instruction 1318 goes beyond the start of the block... to get 0s? I really don't get it.
***************************************
Compressed picture
4104 5449 4D32 0400 0100 0000 0118 3004
UKID ITVL
0100 0004 0510 0100 3000 0001 0001 0305
ITVL
UK = Unknown
ID = counter?
LTR? = Literal? char to copy?(2 bytes)
IT = Instruction
VL = Value(num times)
Value seems to be 8 bits(shift 3 bits)
11111000
1 = repeat count
0 = unk (flags?)
The IT(Instruction):
The it has the number of spaces to go back in the first 5 bits
count 2 bytes before that position to get the literal to copy for the run.
flags(last 3 bits) are still unknown.
if there is no count in the literal or the value then delete and do nothing.
maybe the literal must also exceed the 32 bytes(or 12) or something.
- Spacing is 32 bytes(maximum length of compressed output.)
*************************************
ROLF and don't ask me what it mean! I can't understand what I wrote and is probably incorrect as I write what I discover as I go. the file I recovered from a dead file system and could not retrieve the time stamp so I don't know if it is the latest >.<
Just remembered: that data is wrong, back then I though there where 2 types of data one that was UKID and the ITVL but they are actualy both the same ITVL - instruction and value(2 bytes) is just I didn;t understand the part with the header.
Edit:
At 0x54 in yokotex1.sld and 0xCC in the uncompressed file
Compressed:
0208 080F 0600 1318 0101 0118 0303 0103 0210
ITVL = 1318, 0118, 0210
1318: don't get it but has a run of 3
0118: go back 1(2 byte pairs, first entry in index?) repeat 3 times
01 index number
18 = 00011000 shifting to the right 3 times gives us 00000011(3)
0210: select 4 bytes as the literal... ? copy 2 times
the uncompressed file shows this:
0208 080F 0600 0000 0000 0000 0101 0101
0101 0101 0303 0103 0303 0103
it is pretty close :)
IT must be 4 bits long since it uses pairs of 2, if it was 5 bits the IT will be able to go before the begining of the block that is 32 bytes.
instruction 1318 goes beyond the start of the block... to get 0s? I really don't get it.
- Jamesuminator
- advanced
- Posts: 41
- Joined: Sun Mar 02, 2008 12:13 am
- Location: Toronto, Ontario
- Been thanked: 2 times
- Contact:
Re:
Hmm, i'm sort of way over my head, but i like math :P.alera wrote:Yes it does, all files start with that or 44h I believe :) found some notes:
***************************************
Compressed picture
4104 5449 4D32 0400 0100 0000 0118 3004
UKID ITVL
0100 0004 0510 0100 3000 0001 0001 0305
ITVL
UK = Unknown
ID = counter?
LTR? = Literal? char to copy?(2 bytes)
IT = Instruction
VL = Value(num times)
Value seems to be 8 bits(shift 3 bits)
11111000
1 = repeat count
0 = unk (flags?)
The IT(Instruction):
The it has the number of spaces to go back in the first 5 bits
count 2 bytes before that position to get the literal to copy for the run.
flags(last 3 bits) are still unknown.
if there is no count in the literal or the value then delete and do nothing.
maybe the literal must also exceed the 32 bytes(or 12) or something.
- Spacing is 32 bytes(maximum length of compressed output.)
*************************************
ROLF and don't ask me what it mean! I can't understand what I wrote and is probably incorrect as I write what I discover as I go. the file I recovered from a dead file system and could not retrieve the time stamp so I don't know if it is the latest >.<
Just remembered: that data is wrong, back then I though there where 2 types of data one that was UKID and the ITVL but they are actualy both the same ITVL - instruction and value(2 bytes) is just I didn;t understand the part with the header.
Edit:
At 0x54 in yokotex1.sld and 0xCC in the uncompressed file
Compressed:
0208 080F 0600 1318 0101 0118 0303 0103 0210
ITVL = 1318, 0118, 0210
1318: don't get it but has a run of 3
0118: go back 1(2 byte pairs, first entry in index?) repeat 3 times
01 index number
18 = 00011000 shifting to the right 3 times gives us 00000011(3)
0210: select 4 bytes as the literal... ? copy 2 times
the uncompressed file shows this:
0208 080F 0600 0000 0000 0000 0101 0101
0101 0101 0303 0103 0303 0103
it is pretty close :)
IT must be 4 bits long since it uses pairs of 2, if it was 5 bits the IT will be able to go before the begining of the block that is 32 bytes.
instruction 1318 goes beyond the start of the block... to get 0s? I really don't get it.
I'm thinking the instruction is actually 4 bit values and not a byte.
let me explain
Compressed:
Code: Select all
0208 080F 0600 1318 0101 0118 0303 0103 0210
Code: Select all
ITVL = 1318
what if it's actually:
true is 0 cushion, false is repetition = 1 /*from what I've seen, consistent*/
how many pairs of bytes = 3 /*consistent*/
loop how many times = 1 /*consistent but fishy, again i'm over my head*/
how many bits?* = 8 /*see below*/
*I'm not sure about this one, by this i mean, how many bits it's reading, if we have two bytes that are this
0000 1111 0000 1011, the first 4 bits of each byte is unused, maybe it cancels it out?
unlikely seeing as the 0101 is kept the same, but still plausible
Code: Select all
0208 080F 0600 0000 0000 0000 0101 0101
0101 0101 0303 0103 0303 0103
Feel free to correct me if i'm wrong :)
Also, sorry if i confuse anyone, i have a poor way of explaining myself.