No it hasn't (!!). I have a panel at 4:3 ratio that I've started converting to widescreen. The bitmaps in it were rather large (excessively so, if I'm honest!) so I decided to reduce the sizes while I was at it. I also saved the larger bitmaps as 16-bit rather than 24-bit to try and reduce the gauge size further. The original 4:3 gauge with the huge 24-bit bitmaps compiles to a size of 430Mb and loads and runs with no trouble. The widescreen gauge with the resized, saved-as-16-bit bitmaps complies down to 290Mb and I get the above error when trying to open a second panel. Somehow, that doesn't seem to make sense.

 

Has anyone any idea where I went wrong? Also, looking at my memory usage, would I be right in guessing that FS can't access more than 4Gb? Secondly (another guess) it's not a good idea to mix 24-bit and 16-bit within one gauge? Possibly the source of the problem?

 

-Dai

2D panel bitmaps should be either 8 or 24 bit,

 

As for the file size, something is wrong.

 

A 24 bit bitmap that is 430 MB would be way to big for FS to even recognize.

 

regards,

Joe

In addition to the above that Joe wrote, the error message itself is misleading...

 

This is a topic that has been cussed and discussed thousands of times over the past many years. The actual problem is that FS (any version) is a 32 bit executable. As such, the absolute maximum size of the Virtual Address Space (VAS) table is ~4GB, and even that is only possible if the operating system is 64bit. If the OS is 32bit, then the max absolute size is limited to ~2GB.

 

Note that the VAS table itself is simply mapping the program's memory footprint within the physical RAM. It is not the contents of the program or data itself.

 

In your specific instance Dai, the problem is the attempt to use a 16bit bitmap. Actually 8bit is usually adequate for 2d panels.

 

References:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366912(v=vs.85).aspx

https://en.wikipedia.org/wiki/Virtual_address_space

@Joe: the total gauge size is 430Mb, not just the size of a single bitmap.

 

@Bill: I thought the 16-bit bitmaps were the problem. Crap. I've left myself with a huge amount of rework.

 

Thanks guys - and apologies for not using the search function correctly.

 

-Dai

As it turns out, none of the above is the problem. First thing I did was to restore a full set of 24-bit bitmaps, reduce them to a quarter of the original size and still save as 24-bit. Indexing and saving as 8-bit wasn't acceptable because it blurred some features too much (FS can do what it likes when it loads them :ph34r: ). Anyway, FS still crashed. So, on my commute home at midnight last night I decided I really had to apply some logic to this and try to nail down just where the problem is coming from.

 

1. I upgraded to VS2013 and the problem started. There's a compiler library change in VS2013, so maybe that's it.

3. Okay, pull back a known-working three-week-old copy of the 4:3 panel and recompile in VS2013

4. It runs, so it's not the compiler change

5. Load the 16:10 gauge using the 4:3 panel.cfg file

6. It runs, so it's not the bitmaps

7. Load the 4:3 gauge using the 16:10 panel.cfg file

8. FS crashes with an 'out of memory' error

 

Conclusion: I've made a right bollox mess of the 16:10 panel.cfg file somewhere. I'll update this when I find the faulty line/section.

 

-Dai

Well, as expected, it turned out to be something unexpected  I have a forward facing panel (Window00) with a transparent background and a number of panels that need to be active when the panel loads, all sized at 0,0,1,1. The 'real' 2D forward view is WIndow01 and is part of the gauge. The panelbg.bmp file in the \panel folder is 1175x888 (I can't remember why that size). While going through my size-reducing exercise I resized that panel to 100x76 and changed the panel.cfg file to suit.

 

file=panelbg.bmp
size_mm=100

 

This was what was causing the 'out of memory' error. As soon as I went back to the original panelbg.bmp size and changed the panel.cfg file back to

 

size_mm=1024

 

- the 'out of memory' errors ceased.

My advice is 8bit all the way. Gauges and panel bitmap load times are decreased dramatically.

 

For panel bitmaps experiment with different formats to retain quality if necessary when saving.

 

If you want speed and clarity panel bitmap should be screen resolution (in my case 1600x1200) and saving as 8bit will also give you clear edges for transparency (cockpit windows)

Thanks for the advice Ed. My bitmaps are screen resolution (for me, anyway), but I guess I really should give 8-bit a try.