I think it would be fun to play a HD op2 of some sort
I can agree with that.
leeor_net!
Outpost 2 uses palettized images. One of the reasons is the way day/night is handled. The game will create several pre-scaled copies of the palette, with different light intensities. When it draws the graphics, it looks up which palette to use based on the day/night light intensity. The actual image itself is not modified, just the palette used to display that image.
Another complication is the player colors drawn on units. This is again done through palette trickery.
I believe the tile sets check the bit depth, so a 24 bit image would fail to load. I think a 16 bit image might load, but assumptions about the use of a palette could cause a crash. For the sprites, I don't believe it stores a bit depth so much as an image type, which has an implied bit depth. Shadow images would have a bit depth of 1. Normal images would have a bit depth of 8.
Total maps colors may exceed 256 colors (8 bits), since each tileset has it's own palette, and a map consists of multiple tilesets. You can break tiles up into tilesets based on common colors, and which tiles can share a palette.
The total colors in one frame of animation may exceed 256 colors (8 bits), due to the game using composite images. A vehicle might consist of separate images for the wheels/tracks, the chasis, the turret, and the shadow(s). Similarly, buildings would have separate images for the dock, the building itself, and the shadow.
The sprite image data is split between OP2_ART.BMP and OP2_ART.PRT (stored in maps.vol). The BMP file is structured like a regular BMP file, but with invalid header fields and is not viewable with normal bitmap editing software. It contains a dummy header, followed by all bitmap data for all game graphics, appended one after another in the file. Since the interpretation of the bitmap data depends on header info, and each image has different header parameters, there is no way to interpret this file with one single header and get sensible data out of it. It is simply the raw bits, interpreted according to external info.
The PRT file contains the info needed to interpret the bitmap data. It starts with an array of palettes. Then it contains an array of header information (width, height, bit depth, palette index), with offsets into the BMP file for the chunk of data each header describes. It also contains an array of animation info, where each animation has an array of frames, and each frame references several component images, as described above.
This is the nature of the images you would be editing. The game only understand this format. It would likely by done by extracting and editing numbered images. When those images are re-inserted, they would be composed into frames, which would be placed in animation sequences.
The easiest starter project would be to change just the images without modifying width, height, bit depth, or how frames or animation sequences are composed. That could even be done by careful copy/paste with a hex editor. You could copy the bitmap data (excluding the header) from an extracted edited bitmap, back into OP2_ART.BMP, without needing to modify OP2_ART.PRT, assuming you figured out the right size and offsets for the copy/paste. The image extraction software might be able to help figure out the paste offset.
More advanced editing will mean re-writing the PRT data. Do-able, but some tooling would need to be developed to make that easy.
@Sirbomber: lol
Looks like some bad re-pack offsets