.MIP files and developing a new tool

[checkpoint10]

Sounds like the original concept for Icr2mgr - one stop for all your Icr2 editing needs. Good luck, it's a daunting task.

I don't recall there being duplicated rows of pixels at the top and bottom of each sub-image. I'm not saying they're not there, just that I think it would be an odd enough thing to have to deal with that it seems like I would remember it.

Scaling palletized images is a surprisingly complex thing. WinMip basically sidesteps the process in return for speed; it's generally ok but can yield unexpected results.

Mips are about the most complicated bits of the whole game, so take your time and do lots of testing as you go.

Depending on the tools you write, .dat files only need to be unpacked if the sizes of included files are being changed.

Thanks for the advice, Bob. I must confess that I couldn't get ICR2Mgr to work previously, but I just spent some time with the old installation thread on this form, and played around in RegEdit and finally got it to work! I definitely should have paid tribute to your tool - my apologies - and if I can make something worthy of the title, would you allow me to call it ICR2 Manager 2.0? ;-)

You wrote some great documentation in the Help file - for example, I was going to ask you what is the best way to scale down the MIP file, but your documentation already describes this process. I recall in another thread that you lost the source code but do you happen to have any other notes that might be helpful?

So far, I have some code that can unpack a .dat file and read a MIP file and show it on screen, which is when I felt good enough to create this forum thread. My next challenges are:
1) Converting the file to .bmp
2) Converting the .bmp back to MIP file, including making the subimages
3) Packing the .dat file back up

After that, I think creating a UI and integrating drivers2.txt should be straightforward and my biggest challenge would just be carving out spare time :-D

As for the MIP file having duplicate rows... I only noticed this when I was trying to figure out why there was a difference between the starting offsets as defined in the header, versus if I just recalculate it by adding the image size to the previous starting offset. For example, in a file that was generated by the default Paintkit, the main image starts at 232 and the next one starts at 21544. The image dimensions are 128x165, so the size is 21120. If you add 21120 to 232, it leaves a gap of 192. I went into a hex editor to find that this is actually a duplicate of the last row of the first image (128) plus the first row of the second image (64). The same thing recurs between each subimage. Maybe this is irrelevant to ICR2 if it can still read a .MIP file without the gap part, but I will test that later.