I've got an ADI gauge that I wrote for FS2002. It worked fine in FS2002 and FS9. Unfortunately, one of the graphic elements (a SLIDER) isn't displaying properly in FSX. What I've got are two SLIDER elements (glideslope and localiser needles) that display on top of the main SPRITE element. The localiser displays just fine (3 pixel x 20 pixel bitmap). The glideslope looks like a stretched ellipse (3 pixels high by 20 pixels long). Any thoughts as to why this bitmap isn't displaying properly? I've checked the bitmap image to make sure it hasn't been corrupted. It looks fine. I've also played around with changing the memory locations in the resource file. Didn't make any difference. William Call

Hi BillI don't have a smart answer but I do have a suggestion. Go back to the source code and delete the glideslope macro, then copy'n'paste the localiser macro and change the references to point back to the glideslope stuff. On the face of it this looks like a complete waste of time but I've had just such an action work on numerous occasions when 'this' worked and the almost identical 'that' didn't. It was almost as if a character above ASCII 128 had gotten into the code and I couldn't find it. On one frustrating occasion I ripped out the entire macro stack and re-wrote it (no copy'n'paste!), leaving all the other code intact. It fixed the non-display problem I was having....-Dai

Dai, Good to hear from you! Thanks for the suggestion (will do)! Thinking that this maybe a system problem, I rolled back my display device drivers, no change in the display of this element. I'll post my findings. Bill

I did the following:1) commented out the glideslope SLIDER macro2) cut/paste the localiser SLIDER macro in its place3) edited the localiser SLIDER macro to use the glideslope bitmap and callbackThe results were the same. Instead of a horizontal line for the glideslope needle, I get a "stretched ellipse", 3 pixels high by 20 pixels long Bill

Hi BillWell, I've got one other suggestion.... mail me the code and I'll compile it?-Dai

Hi BillFile received okay. I'll take a wee squinty at it tomorrow (today?). Monday, anyway.-Dai

Problem solved, thanks to Dai Griffiths. The changes that I made to the memory locations in the resource file were not big enough. After adding 0x5000 (hex) to the resource file locations, the bitmap element in question now displays properly. Thanks for all your help, Dai!

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...Further complicating the issue is that in FSX, a resource number offset precisely 40,000 (decimal) is used for auto-swapping a night version of the base resource number's bitmap.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-0x07F3 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-0x62F3NOTE: A handy site for hex-decimal-binary conversion is:http://flor.nl/dec2hex.htmlIt'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 in resource numbers is still respected, which is why you had a problem... ;)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, 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! ;)

Surprisingly enough, Bill, I always use decimal spacing, cosy them all up together and don't have any problems. I started doing this years ago because I got considerably peeved with the VS IDE complaining about hex numbers not being valid for resources every time I loaded a project. The only minor problem you have to watch out for is the x9-x0 jump for mask and multiple images in one MAKE_ICON.-Dai

Bill, Thanks for the info. My gauge cluster has between 50 and 60 gauges, with about 300 bitmap resources. I'll check to see if the bitmap image in question is outside the "safe". I'm sure you're correct. William Call

Well, there's no reason not to use decimal numbers if you prefer.Frankly for most projects I used hex, but treated 'em like decimals, incrementing by 10 for each resource, pretending that numbers a-f didn't exist, etc. ;)However, since I grew tired of chasing down resource conflicts, I've opted to use the scheme posted because it will positively, without question not allow conflicts to occur... ;)I used to get headaches when dealing with upward of 500+ bitmap resources in a multi-gauge because of having to keep the following "rules" in mind all the time (decimal based). Every bitmap/resource used actually uses four resource allocations:1000 - Basic bitmap resource1500 - Reserved for a hi-res version of the basic bitmap41000 - Night-time version of the basic resource bitmap41500 - Reserved for a hi-res night-time version of the baeic resource bitmapPhooey on all that! I use the table now exclusively... ;)