Gauges: Resource Numbering
Original Entry: Bill Leaming
One of the major shortcomings of the SDK is that absolutely no mention is made of the requirements for resource numbers, including the various auto-offsets that the panel system will look for...
Every bitmap used in a C gauge's .rc file requires a resource number allocated in the gauge's .h file.
Each such resource allocation actually reserves FOUR resource numbers (in FSX) although only TWO in FS9 and earlier gauges.
For example (using decimal numbers), the background image for a gauge might be 1000. Therefore, the following table applies:
1000 - background image
1500 - optional hi-resolution version of background image
41000 - optional night version of background image (FSX+ only)
41500 - optional night version of hi-res background image (FSX+ only)
So, even if we don't provide any of the "optional" bitmaps, the resource numbers are already "reserved," hence unavailable for use by any other bitmaps!
Some months ago, Jean-Luc suggested one possible scheme that at least has the virtue of being guaranteed "safe," since it takes into account all of the conditions placed by the panel system on resource numbers.
I've since expanded the list to take advantage of the full dynamic range of allowable numbers. Below is the complete list of "Safe Ranges:"
// 0x0100-0x02F3 0x0500-0x06F3 0x0900-0x0AF3
// 0x1100-0x12F3 0x1500-0x16F3 0x1900-0x1AF3
// 0x2100-0x22F3 0x2500-0x26F3 0x2900-0x2AF3
// 0x3100-0x32F3 0x3500-0x36F3 0x3900-0x3AF3
// 0x4100-0x42F3 0x4500-0x46F3 0x4900-0x4AF3
// 0x5100-0x52F3 0x5500-0x56F3 0x5900-0x6AF3
// 0x6100-0x62F3
NOTE: A handy site for hex-decimal-binary conversion is: http://flor.nl/dec2hex.html
It's critical to recognize that, even though the "old system" of dual-resolution bitmaps is no longer canon for FSX gauge code, because of the necessity for "backwards compatibility" the auto-offset of 500(decimal) in resource numbers is still respected.
Of course, this is only one possible scheme, but it has the advantage of being rational and consistent. As long as you allocate resources within these ranges, you will NEVER run into a problem with contention. :)
The complete range of allowable resources is of course 0x0000 to 0xffff. The reason the above table stops at 0x62f3 is because in FSX, if one takes into account the 40,000 (decimal) auto-offset that the night time bitmap "swap code" looks for, then the highest possible number would be 0x63bf, which of course one could use, but it "breaks" the consistency of the tabular range scheme. ;)
Aside from which, with 9,500 allowable id's, I cannot conceive of any multigauge cluster that would come close to exhausting the list of numbers provided by restricting one's choices to the table's range...
...at least not one which would actually load and run efficiently!
