Allow organizing image data from .prt and modified .bmp files into standard format

[Brett208]

I was thinking about the best way to do this. I think we want to avoid adding third party image libraries to OP2Utility unless really needed.

We could probably handle getting the data into a standard BMP file in house without too much trouble as I think the format is fairly simple. This would allow for testing from within OP2Utility to ensure that data is being read and written properly from the different sources.

We will probably want to also support some more complex image manipulation options such as pushing the data into a PNG format or an animated GIF format. This sort of work would probably be best using a library instead of home-rolling and could be done by the frontend application.

So the application itself would receive the image data either as a fully formed, standard BMP file, or some sort of standard BMP memory stream. It would then further manipulate the data. The gray area that I haven't looked into is how to handle BMP transformations onto Sprite Sheets. For example, combining multiple frames either on top of each other or into a larger sprite sheet.

If these look not to bad to accomplish in house, we could allow OP2Utility to pass sprite sheets in BMP form. If not, we could use the front end application to transform the well formed BMP streams as needed. This effort should probably be conducted on a different issue. This issue should probably just focus on getting individual frames written to BMP.

Open to suggestions on the overall design though.

Thanks,
Brett

[DanRStevens]

Hmm, yes, I think we can handle BMP in house. The game is very minimal with how it handles the image data. Initially we can probably get away with just handling BMP format.

Later on it would be nice to handle PNG, and GIF too. I would want to use a library for that. I think there is a "libpng". I'm not sure about GIF. Meanwhile though, we can always just use external converters if we need those other formats.

[Brett208]

I have a script that produces a mostly well formed BMP file on my local computer now. I was trying a monochrome bitmap for starters. The tough parts seems to be when pixels are represented by units smaller than a byte and extending each row of pixels to be a modulus of 4 bytes.

For a 1 or 4 bit count image, I think bitwise manipulation will be required when extending each row to a multiple of 4 bytes.

-Brett

[DanRStevens]

Good job!

Yes, there will be some format conversions required. I believe most image layers are 8-bit per pixel images using a palette. A few, such as the shadows, are 1-bit per pixel.

I assume you're referring to the scanlineByteWidth, or "pitch" when you mention the multiple of 4 bytes. I don't believe it it strictly necessary, but can potentially be a performance optimization, as each scanline is then aligned, leading to faster read access when processing by 32-bit chunks. It may require wasted padding bytes at the end of each scanline though.

In terms of the alignment math, roundDown4(x) = x & ~3, while roundUp4(x) = (x + 3) & ~3.

[Brett208]

Yes, I am referring to the scanLineByteWidth. It appears that the file is not considered valid unless the scanLineByteWidth is properly adherred to based on initial experience and some initial reading. Although I haven't put enough time in to say for sure.

Thanks for pointing out the bitwise math. I'll look them over closely later today and see if I can get it working.

[Brett208]

The alignment math for rounding up is definitely working.

I have 8 bit OP2 bitmaps saving to disk as well formed standard BMPs. I haven't played with the 1 bit shadows much yet.

For reference, the packed bitmaps are already 4 byte aligned.

I'd like to spend more time cleaning the code before posting. Otherwise @DanRStevens will be commenting on a lot of areas that I already know need cleaning.

I have a set of classes that write standardized bitmaps to disk without any real connection to Outpost 2. All platform agnostic and home rolled. Then I have a class serving as a bridge that translates the data from Outpost 2 specifics to what the bitmap writer wants to see. This has allowed me to write both bitmaps independent of Outpost 2 for testing and Outpost 2 specific.

There are a fair number of edge BMP features that are not yet implemented such as palettes smaller than their max size, most important palette indices, compression, etc. We don't need these features, so we probably need to decide which ones are low hanging fruit and worth adding for completeness and which ones are time sinks that should be avoided since we are not creating a robust bitmap writing class.

-Brett

[Brett208]

We can successfully create a bitmap file from the OP2 specific .prt and .bmp files. I'm going to close this branch as having been successful.