Did anyone manage to rip RRT2's sprites?

[eldomtom2]

I'm trying to do this myself. Unpacking the vanilla .paks that contain the data is no problem, but so far I haven't found anyone who can decode the .imb files that presumably contain the actual sprites.

[Gumboots]

The .imb files are just a record of which part of the sprite is used by each icon. It's not the sprite itself (that would be a .DDS image).

[eldomtom2]

Are you sure? That may be the case for RRT3, but RRT2's .imb files are the biggest in the .pak - I can't see why they be that big if they weren't the actual sprites, and there aren't any .dds files or other image files in the .paks.

[Gumboots]

Ok, in that case the DDS must be in there somewhere. RT3 does a similar thing with scenario maps. The map texture/skin is a .jpg that is coded as part of the .gmp, and is placed at the end of the file.

I'd look for an obvious change of format. I don't know what the innards of an RT2 .imb look like, but in RT3 they are just a list of various asset names, and coordinates for which portion of the sprite they use. So if RT2's are basically the same, the part where it changes to coding for an embedded .DDS should be fairly obvious. To help spot it, it would probably be useful to open a handy existing .DDS in a hex editor and check out what the header looks like, then search for that (or parts of it) in the RT2 .imb.

If the .imb starts with asset names and coordinates, the logical place for an embedded .DDS would be after all the asset definitions. So, alternatively, you could search for the last asset definition, and see what comes after it.

[eldomtom2]

So if RT2's are basically the same

Unfortunately they are not. You can throw one of RRT3's .imbs into a hex editor and it'll produce actual text; no such luck with RRT2's.

[Gumboots]

That's awkward. Have you tried asking over at The Terminal?
Most of the RT2 diehards are over there. One of them may know something.

[eldomtom2]

I have already made a post there, however there has been no response yet. I suppose I shall have to wait and see.

[eldomtom2]

A small update - after looking at the files in a hex editor, the first seven lines appear to be a header of some kind. Here are some examples:

29 00 00 00 03 00 00 00 CE 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 80 B5 82 01 00 00 00 01 00 00 00 01 00 2A 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 5F 00 00 00 63 00 00 00 DC 80 B5 82 B3 1B 00 00 0C

01 00 00 00 03 00 00 00 F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C4 93 9C 82 01 00 00 00 01 00 00 00 01 00 2A 00 00 00 00 03 00 00 00 18 00 00 00 08 00 00 00 F0 00 00 00 03 01 00 00 38 F0 1B 83 0D D0 00 00 29

08 00 00 00 03 00 00 00 BF 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 30 14 BF 82 02 00 00 00 01 00 00 00 01 00 2A 00 00 00 00 03 00 00 00 F9 FF FF FF EE FF FF FF 0E 00 00 00 16 00 00 00 A4 14 BF 82 35 01 00 00 04

Maybe these are recognisable to someone.

[Gumboots]

I did see this, but can't help. I agree that at least some of it is likely to be a header, but at a glance I can see that there is considerable variation between the three examples. You could surmise that the 03 for bytes 9 and 10, and the sequence 82 01 00 00 00 01 00 00 00 01 00 2A 00 00 00 00 03, are standard header code, but what it does is beyond me.

[eldomtom2]

I don't know if any of this will be helpful to you, but I've been talking with someone on another forum and have managed to get a lot of jargon-heavy information out of him.

29 00 00 00 03 00 00 00 CE 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 80 B5 82 01 00 00 00 01 00 00 00 01 00 2A 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 5F 00 00 00 63 00 00 00 DC 80 B5 82 B3 1B 00 00 0C

My guesses:

00 00 00 29 - number of sprites in this file

next bytes you provided are the header for first sprite
...
00 00 00 5F - something like width of sprite (not exactly)
00 00 00 63 - something like height of sprite (not exactly)
...
00 00 1B B3 - size of sprite body (starting from last byte of provided header).
<sprite body>
<next header> (if any)

As for "not exactly" part - for Credits.IMB dimencions in header are 400h * 300h, while real data are 40Ch * 300h.
Image is divided by 7 one-pixel vertical lines and has 2 two-pixel vertical lines on the borders. But it's still Bh out of extra 0Сh. Size of blocks between vertical lines is 80h, so it may be somehow connected to the value of the last header byte (84h for Credits).

Size of real data is provided in header.
"Real" dimensions could be found for some non-compressed sprites in programs for visualization of raw data. I used GBS.

I extract sprites using any program that allows to copy parts of the binary file. Many hex-editors can do this, but I used dd utility:

dd if=CREDITS.IMB bs=1 skip=$((0x70)) count=$((0xC2401)) of=00.sprite

dd if=WINLOSE.IMB bs=1 skip=$((0x70)) count=$((0x451A9)) of=00.sprite

Instructions: https://stackoverflow.com/questions/142 ... hin-a-file

Sprites are compressed. Simple cases like CREDITS can be decompressed with something like this:

int position = 0;
int destPos = 0;
boolean finish = false;
while (!finish) {
int lineStartPos = destPos;
int firstByte = readByte(source, position++);
if ((firstByte & 0x80) > 0) position++;
boolean lineFinished = false;
while (!lineFinished && !finish) {
int controlByte = readByte(source, position++);
if ((controlByte & 0x80) > 0) {
if ((controlByte & 0x40) > 0) {
int skipSize = controlByte & 0x3F;
if (skipSize == 0) {
finish = true;
} else {
destPos += skipSize;
}
} else if ((controlByte & 0x20) == 0) {
// !TODO
} else {
// !TODO
}
} else if (controlByte == 0) {
destPos = lineStartPos + width;
lineFinished = true;
} else {
for (int i=0; i<controlByte; i++) result[destPos++] = source[position++];
}
}
}

Maybe you can make more sense of that than I can, programming was never my forte.

[Gumboots]

It means nothing to me.

[eldomtom2]

I am pleased to say that my discussions on the other forum have resulted in programs to rip RRT2's sprites and pallettes, though they won't rip transparent sprites.

[Gumboots]

Excellent.