02-09-2019, 05:16 AM
Lately, I've been doing Python programming as a hobby and as an interesting project, I was thinking of making a new tool that will unpack/pack .dat files, read/write .mip files and some built-in editing of the drivers2.txt file as well.
Why a new tool when we already have the likes of DooDAT and Winmip etc.? Well, these tools are many years old and, especially in the case of Winmip, difficult to get running on modern systems. I am also attracted to the idea of making an all-integrated editor similar to GP2Edit if anyone remembers that. Something easy to use even for editing the new carshapes. Finally, to ensure that knowledge is never lost, I would make this tool open source and share everything I learn.
The .dat file structure is straightforward and is documented in the ICR2 "Complete Reference Book", however I could not find any documentation for the .mip file. So, after a couple days of research and coding, here is what I found:
Byte/Description
00-03 - File size, not including this 4-byte header
04-07 - None, but always zero
08-11 - Main image width
12-15 - Main image height
16-19 - Number of images in file (including main image)
20-23 - Unknown, possibly a color
24-27 - Image width minus 1
28 - Unknown - seems to be zero
29 - Unknown - is FE if number of images = 8, otherwise FF
30-31 - Unknown, always FF FF
32-35 - Starting offset of the first (main) image, minus 4 (e.g. if the value here is 232, the offset is actually 236)
The following repeats based on how many images are in the file.
36 - Has to do with image scaling (these are consistent between files that have similar number of images, I have a table of values as to what they should be)
37-39 - Probably has to do image scaling as well - always 00 00 00
40 - See 36
41-43 - Probably has to do image scaling as well - always FF FF FF
44-47 - Starting offset of the nth image, minus 4
There is some gap between the header and actual data, around 192 bytes but I think maybe depends on the number of images.
The actual data part:
1) The images are uncompressed, like a bitmap file. Each single byte represents the color index in the color palette.
2) The last row of one image is duplicated, as is the first row of the next image, before the file moves into the real image data for the next image. The starting offsets in 44-47 only define where the real images begin.
Why a new tool when we already have the likes of DooDAT and Winmip etc.? Well, these tools are many years old and, especially in the case of Winmip, difficult to get running on modern systems. I am also attracted to the idea of making an all-integrated editor similar to GP2Edit if anyone remembers that. Something easy to use even for editing the new carshapes. Finally, to ensure that knowledge is never lost, I would make this tool open source and share everything I learn.
The .dat file structure is straightforward and is documented in the ICR2 "Complete Reference Book", however I could not find any documentation for the .mip file. So, after a couple days of research and coding, here is what I found:
Byte/Description
00-03 - File size, not including this 4-byte header
04-07 - None, but always zero
08-11 - Main image width
12-15 - Main image height
16-19 - Number of images in file (including main image)
20-23 - Unknown, possibly a color
24-27 - Image width minus 1
28 - Unknown - seems to be zero
29 - Unknown - is FE if number of images = 8, otherwise FF
30-31 - Unknown, always FF FF
32-35 - Starting offset of the first (main) image, minus 4 (e.g. if the value here is 232, the offset is actually 236)
The following repeats based on how many images are in the file.
36 - Has to do with image scaling (these are consistent between files that have similar number of images, I have a table of values as to what they should be)
37-39 - Probably has to do image scaling as well - always 00 00 00
40 - See 36
41-43 - Probably has to do image scaling as well - always FF FF FF
44-47 - Starting offset of the nth image, minus 4
There is some gap between the header and actual data, around 192 bytes but I think maybe depends on the number of images.
The actual data part:
1) The images are uncompressed, like a bitmap file. Each single byte represents the color index in the color palette.
2) The last row of one image is duplicated, as is the first row of the next image, before the file moves into the real image data for the next image. The starting offsets in 44-47 only define where the real images begin.