Recent Posts

Pages: 1 [2] 3 4 ... 10
11
News / Re: Outpost 2 1.4.0 community-supported update released
« Last post by Monarky2000 on March 16, 2021, 09:17:36 AM »
Here is a link to the Deviant Art page. Been over a month have not heard anything. Community pretty much dead?

https://www.deviantart.com/monarky/art/Outpost2-873402558
12
Outpost 3D / Re: Want Ot Know About The Project
« Last post by lordpalandus on March 15, 2021, 11:24:18 PM »
You've not been here a while, so welcome back, Celledor.
13
Outpost 3D / Re: Want Ot Know About The Project
« Last post by Celledor on March 09, 2021, 04:46:56 AM »
I have tried to restart this project several times now, but just haven't found the time. However it is still a dream to do so and with many successfull remakes and remasters coming out I think it is possible. Will continue to try and find the time, hopefully one day. New versions of unity and other tools makes it esier than ever to do so.
14
Projects / Re: OP2 Mission Editor
« Last post by Vagabond on March 06, 2021, 07:26:09 AM »
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.
15
OutpostHD / Re: [Bug] Loading game fails on turn 1
« Last post by Kyrros on March 05, 2021, 07:43:57 PM »
..\roaming\LairWorks

Got it  ;D
16
Projects / Re: OP2 Mission Editor
« Last post by TechCor on March 05, 2021, 07:08:10 PM »
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.
17
Projects / Re: OP2 Mission Editor
« Last post by Vagabond on March 05, 2021, 10:55:41 AM »
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.
18
OutpostHD / Re: [Bug] Loading game fails on turn 1
« Last post by leeor_net on March 05, 2021, 10:21:55 AM »
Yup. Aware of this -- it's fixed in 0.8.2.  ;D

Thanks for the report!

This is due to some code making assumptions about where the Command Center is located. That "out of bounds {-1, -1}" message is indicating that there is no CC built (default coords) but the game is assuming one has been built.



I use imgbb.com to do inline images. It has the problem of over time if a user removes images the link breaks. After you upload an image, you can copy the address of the image you uploaded, edit your message and use that image address to inline it. It's a bit of a kludge but it works.



Save games are saved in the user directory under AppData. On my system, my username is 'leeor' so the path is this:

C:\Users\leeor\AppData\Roaming\LairWorks

It'll be something similar for you. This is done to comply with Microsofts best practices for handling user data outside of program data.
19
OutpostHD / Re: OutpostHD v0.8.1 Released!
« Last post by leeor_net on March 05, 2021, 07:29:25 AM »
Thank you for your continued interest!

I would just stick with 0.8.1 -- fixes a number of issues in 0.8.0.

0.8.2 is also pretty close to being released so keep an eye out for it!
20
Projects / Re: OP2 Mission Editor
« Last post by TechCor on March 05, 2021, 06:58:48 AM »
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.
Pages: 1 [2] 3 4 ... 10