.MIP files and developing a new tool
#1
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.
Reply
#2
Like this a lot, if i could edit Drivers2 & track txt files without opening multiple files that'd be fantastic Smiley
Reply
#3
(02-09-2019, 02:14 PM)JR82 Wrote: Like this a lot, if i could edit Drivers2 & track txt files without opening multiple files that'd be fantastic Smiley

Yep, that's the idea. For drivers2.txt, it would be cool to make a visualizer of the performance ranges, and maybe have the program tell you the average qualifying positions you're going to get from the values. For track txt and other files, maybe a feature to change the parameters (such as tire temps or grip) depending on which season you want to play.
Reply
#4
(02-09-2019, 06:42 PM)checkpoint10 Wrote:
(02-09-2019, 02:14 PM)JR82 Wrote: Like this a lot, if i could edit Drivers2 & track txt files without opening multiple files that'd be fantastic Smiley

Yep, that's the idea. For drivers2.txt, it would be cool to make a visualizer of the performance ranges, and maybe have the program tell you the average qualifying positions you're going to get from the values. For track txt and other files, maybe a feature to change the parameters (such as tire temps or grip) depending on which season you want to play.

Sounds perfect, am currently trying to figure out if any of the values alter DNF's & what exactly Aggression does. also if Drag alters overtaking etc.
Reply
#5
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.
Reply
#6
(02-10-2019, 01:34 AM)CowtownBob Wrote: 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.
Reply
#7
The top row of pixels in the images made by the game's Paintkit contains the colors for unpainted body panels, helmet and crew uniforms in the <carname>.3do. When you use the paintkit to swap a car with a previously-painted livery, it reads that line of pixels to set those colors. But of course that only works with the original carshape, which is why we need to use a separate image for those colors with newer car shapes. The original shape does not map to that line of pixels on the livery image, so it essentially becomes an extra row of pixels in the mip. What you are seeing as duplicate information is just an artifact of that .3do information in row 0.

With the newer carshapes, the texture mapping can go all the way to row 0.

Actually, what I was hoping for in Icr2mgr but couldn't get working in a reasonable time, was using .gif files for the liveries, which would carry the .3do colors and the drivers2.txt information encoded in text blocks.

I'm glad you got the program working. Of course all my notes and documentation are on the same hard drive as the source code... But if I ever come across a cheap SCSI-3 to USB converter, with any luck I can access it and pass it along to you.
Reply
#8
Good point about .3do colors. I do remember back in the day when people could share liveries from Paintkit easily and the .3do colors were conveniently included in the .pcx files. With the new carshapes, it seems you would have to share both the .bmp/.mip and .3do and even then, the average user would have a hard time editing the colors on the .3do (at the moment, I don't even know how it's done but I think the file is simple enough that I can probably make the tool open the .3do and allow the user to edit via an interface).

I wonder, instead of encoding text within a .gif file, what if the tool exported a .bmp file that had an extra row at the top that has those .3do colors? The tool could be set up to use that row to update the .3do file, and ignore that row when converting to a .mip. This would also enable folks to very easily share liveries like in the old days.

Progress update: I was able to get the tool to take a whole folder and pack all the files to a .dat file... and got the resulting file to work in ICR2! I was able to do this with both samsepi0l's Reynard '89 carset and an Indy 1995 carset with the 40 car patch.

So, my next step is to do is to convert a .bmp to a .mip file, so I need to learn how to downscale an image.
Reply
#9
I was thinking of using a .gif not just for the .3do colors, but also for the DINFO line for drivers2.txt and creator info - names of the original painter and most recent modifier. The thing about adding an extra row of pixels is that if the image then gets used by someone who doesn't have your tool, the texture map will be misaligned with the car body.

Find edwrom's tool for .3do colors, it will help. I forget what it's called, sorry.

Scaling the image is fun. I think I got it right in under 100 attempts... or at least not too many over, lol.
Reply
#10
(02-13-2019, 12:25 AM)CowtownBob Wrote: I was thinking of using a .gif not just for the .3do colors, but also for the DINFO line for drivers2.txt and creator info - names of the original painter and most recent modifier. The thing about adding an extra row of pixels is that if the image then gets used by someone who doesn't have your tool, the texture map will be misaligned with the car body.

Find edwrom's tool for .3do colors, it will help. I forget what it's called, sorry.

Scaling the image is fun. I think I got it right in under 100 attempts... or at least not too many over, lol.

Thanks for the help. Just found the tool ("Reynard 99 Paintkit" by Robert Szikszo) digging through these forums. It works in a relatively friendly way - exports a .pcx file that looks like the body panel screen of the Paintkit and you would then edit it in an image editor and then use the tool to convert the .pcx to .3do. It's a pretty slick process, but I might look into making the body panels part of the tool so that you could the .3do directly (maybe assisting the user with a diagram of the panels that changes depending on the carshape).

You're right, if the tool outputs a .bmp with extra rows, it would create compatibility issues with other tools. GIFs might be a little more advanced for me at the moment but I will make note of the idea for the future.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)