OP2 Mission Editor

[Vagabond]

TechCor,

I was trying to use your mission editor to import a map (v0.5.2). When I click import, the bottom of the window shows NullReferenceException: Object reference not set to an instance of an object.

Then the top ribbon becomes unresponsive, I cannot flick on 'File', 'Edit', etc.

The rest of the editor remains responsive.

I'm using the GoG version of Outpost 2, and pointed to C:/games of gold/Outpost2 as the working directory for the mission editor.

The map works properly when used in Outpost 2, so I don't think it is being caused by a corrupt .map file. I tried a second map with same results.

Using Windows 10 64 bit.

Thanks,
Brett

[TechCor]

The editor was built against the old OPU release. Seems to work fine on there.

I'm not clear on why GOG is different.

Logs say that well0000.bmp is found in the GOG directory.
2120 bytes are loaded.
The BMP library then tries to parse the BMP data, but immediately runs into an issue:
The first two bytes (header) does not match an expected BMP format:

Code: [Select]

Read: 16976
Expected: 19778

It then rejects parsing, and later code throws an exception when it tries to use the missing texture.

If I try to skip the header, it just fails later:

Code: [Select]

Unsupported image format: 524288

The GOG format must be different. Perhaps it is compressed and OPU was not? What was different about OPU?

EDIT:
I used the editor to extract well0000.bmp to a file and it can't be viewed (GOG version. OPU-OK). Further investigation shows that this file is stored in different .vol archives. OPU had it in art.vol at size 2102, while GOG has it in maps.vol at 2120. Both are marked as uncompressed. I'm not sure what is going on here.

[Vagabond]

Oh, funny I was just working on this in OP2Utility. Outpost 2 is capable of reading tilessts as 8 bit Windows bmps or a custom bmp-like format. The original game shipped with the custom format you are encountering. We had been shipping with the standard format pre GOG posting. Check Tileset.h in OP2Utility for how to load the custom format. I added after your original port of OP2Utility.

[TechCor]

I have this working and will submit a fixed version soon, but I have a question about OP2Utility.

Code: [Select]

// Read tileset represented by Outpost 2 specific format into memory
// After Reading into memory, reformats into standard 8 bit indexed bitmap before returning results
BitmapFile ReadCustomTileset(Stream::Reader& reader);

This seems to imply that the resulting BitmapFile will be in a standard format.

I used this and then wrote the data back out to a byte array to pass to a third-party library.
While the image would load, it was upside-down due to inverted scan lines.

I see some other manipulation in that function, notably bitmapFile.SwapRedAndBlue(), but it does not call bitmapFile.InvertScanLines()

So the question is: Are inverted scan lines considered "standard format"?

It seems strange to me that I have to check for inverted scan lines before writing out a standard bmp, but it could be a deficiency in the library I'm using.

[Vagabond]

That may be a bug in OP2Utility. It should have presented scan lines correctly after loading and translating into Windows Bitmap file. You probably need to just set the height value to negative to invert. There is sample code in OP2TilesetConverter that I thought was proving it wasn't inverting incorrectly but I probably need to check my assumptions.

[TechCor]

The output looks correct through Windows viewer. The other lib just doesn't invert when the height is negative, so I will just need to check for this.

GOG works correctly. All unit tests are passing.

I am having an issue with BitmapFile.ReadIndexed on OPU 1.3.7 for well0001.bmp in art.vol.

Code: [Select]

The size of pixels does not match the image's height time pitch.

If I remove the exception, the image loads fine.

These are the passed in parameters:

Code: [Select]

VerifyPixelSizeMatchesImageDimensionsWithPitch(bitCount = 8, width = 32, height = 8608, pixelsWithPitchSize = 275458)

The first three parameters look correct based on the file property dialog in file explorer. I am not sure how to verify the last one.

I'm curious if this affects OP2Utility C++. The ported code looks to be identical for this function.

EDIT:
I studied the bitmap format a bit. This looks like a case where the BMP file is not formatted to spec. Windows/OP2 ignore this as there is enough information to correctly parse the file.

The BMP pixel container size is 2 bytes more than what it should be. It has two extra bytes of padding at the end that put it out of the 4-byte alignment specification. It is awkward, but it appears this just gets trimmed by most apps/libraries for rendering since the width/height properties will not use the full container.

For OP2UtilityDotNet, I am going to change the exception to only throw when the file's container size is too small for the width/height/bitCount. If there is extra fat at the end, it will pass validation. This appears to work successfully.

It may be worth considering doing this for OP2Utility C++ as well.

Commit for this change:
Fix for bmp files with excess padding.

[Vagabond]

TechCor,

Interesting that the third party library you are using doesn't understand negative height. I thought that was a pretty important part of the bitmap specification.

I had noticed that whoever did the original conversion of the tilesets in the Outpost Universe release completed the conversion using a non-standard pitch but I never really addressed it.

@Hooman,

What do you think about supporting non-4 byte alignment for pitch? I think you had advocated for this before but I may be remembering wrong. I'm not an expert on the format, but I think TechCor is probably correct that several editors support non-bitmap standard pitch settings, although I'm not sure the specifics on why they are doing this. I think I would agree that we should relax this test condition and allow reading the file if OP2Utility is able to determine pitch settings even when out of standards. Actually, I think that branch I started early last year and just deleted a couple of months ago was to geared towards supporting this but we weren't happy with the specific implementations method I was working towards.

[Hooman]

Oh wow, I'm just seeing this now. I haven't been checking the forums as much recently. I spend much more time over on GitHub these days. Probably doesn't help that I haven't been getting notifications of forum activity.

I don't remember saying anything specific about pitch padding. (I would probably use the term "alignment" for the start address adjustment, and "padding" for size adjustments).

I would recommend to pad to a 4 byte boundary when writing. It might be good to accept any amount of padding when reading.