nhivanye on 13/3/2006 at 17:11

---

Having returned to T3ed after a year's absence and finding the first FM I decide to try (Evicted) comes in at 86Mbytes I decided to look at ways to compressing the IBT files for distribution.

By writing a program to do a block v block comparision with the IBTs which cam with the game I found that Evicted.ibt shared 31,741 blocks in common with the release IBTs and thses blocks could therefore be restored on any machine with the original game and would not need to be distributed. The size of the distributed file would come down from 86Mbytes to 21Mbytes. Hopefully this will make FMs easier to distribute although still not modem user friendly.

If several missions are compressed at once the program uses the earlier missions as a source for the later missions so the IBTs can get even smaller (compressing two copies of evicted as evicted1.ibt and evicted2.ibt the second file compressed size is 1Mbyte!)

I need to do verify the process by rebuilding the original IBT from the compressed file but it looks promising.

The compression program will need redoing as it is very simple minded and pages heavily on my 1Gbyte machine so wouldn't run at all (except perhaps overnight) on a smaller machine but that is easily sorted.

Shadowspawn on 13/3/2006 at 17:24

---

I'm at about the same point. I'm hoping to have a program available this week. (Funny, I used Evicted as my test case also.)

I discovered about 1/2 of the file could be recovered from the existing resources and wouldn't need to be included in the distribution. As soon as I finish up the binary comparision code, to make ABSOLUTELY SURE that the referenced sections are the same, I'll run it on the other FMs and see what the compression would be like.

BTW: As an aid to processing, I wrote a little program to dump out the contents of each IBT file from the originals and leave it around as an ascii file. I only included the name, types, size, and file offset. I read those into memory first, then search those for matches in the FM. The final step is to read the original IBT and check for a binary match. Saves lots of time.

Shadowspawn on 13/3/2006 at 18:23

---

There are so many other things to look at, I'd like to ask you to look at some of them.

There have been many requests to have a non-3DS Max 5.1 matlib builder, so the great unwashed of us who don't have 3DSMax 5.1 can make material libraries. I've only started looking at that. I'm well into a TIM -> 3DS and back converter, I wouldn't want anyone else to go through that nightmare.

I guess some other conversation and other file formats are up for grabs.

Also, is there any way to compress the GMP files? I haven't really looked into those...

Thanks, sorry it's taken me so long to get this done. Too much RL.

Ziemanskye on 13/3/2006 at 19:35

---

Do we need to compress the gmp files, or are you not meaning what I think you are?

I mean they're like 5Mb, and crush tiny like with zip anyway from what I remember.

Ziemanskye on 13/3/2006 at 20:12

---

You have notices that KernalGFXALL.ibt is like a 9Mb file for 180Mb of already compressed textures, right?

Even the matlib folder is bigger, so I guess it doesn't even have all of them in it (though they might be compressed more and the ibt is just the centralised way of moving the matlibs around - I can't remember if TDS had a matlibs folder before I installed the editor)