Weather radar gauge - VC overlay impossible?

[roland_lfor]

Hi, I'm new to FSDeveloper and new to Fsx gauge devpt as well, so please forgive me if I have "newbie" questions (sure I will).
However I'm not new to flight sim world. Started on Amiga with F-18 interceptor (1988 whoua ). I used to develop some programs for Fly! 2, 10 years ago (Squawkbox, multiplayer p2p system...).

I'm working on a weather radar gauge to use with Active Sky Next API. The goal is to have a gauge which can be used in a standalone window, and also integrated in a VC.

I used the ESP Gdi+ sample with dual transparent/opaque gauge which is very usefull. I use also the Gdi+ interpolation capabilities to have nice picture (means not pixelized).

Here is a view in the A2A PA-28 VC, replacing the Gps gauge: (I use Gps buttons to set range/tilt/gain values)



I would like to blend my gauge bitmap with an existing glass cockpit display unit, like the NGX or the Q400 (like an overlay).
My transparent gauge is effectively transparent when I use it as a standalone window:



However I've made many tests and never succeed to get some transparency when installed inside a VC.
I tried to use alpha blending, draw background in RGB(0,0,0,0) or RGB(0,1,1,1), no success.
It seems that as soon as I write a single pixel on my gauge, the whole bitmap surface turns black.

Do you think it's possible?

Thanks

Happy Christmas and happy new year !

Roland

 

[roland_lfor]

When installed in an existing [VCockpitxx] section, the first question is:
- why my gauge is always above the original one (cover its graphics), and not the opposite?
Declaration order in panel.cfg does not seems to make any difference.

Am I supposed to MAKE_STATIC() with the RGB(1,1,1) BMP_BACKGROUND as in the ESP sample, or choose another background RGB value?
It seems that it's impossible to omit IMAGE_CREATE_DIBSECTION in MAKE_STATIC() options.

 

[nirgal76]

Great, i was looking for a weather gauge base on ASN API. Hope you will go to the end of your project.
Think about giving it a real look like a bendix IN-2026a (the unit used by RXP for wx500 product)

Et je suis encore plus content que ce soit un français qui le fasse

 

[roland_lfor]

No ideas to create an overlay/transparency over existing glass cockpit?

 

[taguilo]

No ideas to create an overlay/transparency over existing glass cockpit?

I don't think that would be possible in VC gauges, as the $texture from the model seems to act like a solid background canvas.

Tom

 

[JB3DG]

If they are separate polygons you can. but for one gauge to blend with another underneath it is a different story...

 

[roland_lfor]

Thanks for your answers.
I would perhaps see a possible solution, but quite tricky to implement with DirectX using the P3D PDK. A lot to learn again!
But then FSX is out of game

 

[roland_lfor]

Is some of you are interested, version 0.5 of my gauge is available on AVSIM library, UploadID: 326047

Roland

 

[ronh]

Found it under
http://library.avsim.net/download.php?DLID=188154

 

[roland_lfor]

A new version is available @Avsim library ID188288

It looks like first version was not working with Fsx (only P3D)

Roland

 

[roland_lfor]

Hello,

I continue to work on a better integration in some premium glass cockpits, first target is the Q400.

I see two main subjects in integration: graphics and knob capture.

1. Graphics

1.1 - At this time I'm able to draw the cone of the radar over an underlying gauge display. I add IMAGE_USE_TRANSPARENCY | IMAGE_USE_ALPHA flags in gauge declaration, and draw my black pixels with a 0 alpha value - Color(0,0,0,0). It means that areas outside the cone is not covered by the radar gauge, and original display is still refreshed and displayed by the original gauge.

1.2 - I would like keep the original gauge display inside my cone, in areas where my pixels are black. I can already do that with 1.1 configuration, but then the problem is to erase the radar colors when sweep pass over. In GDI, there are several pixel combination modes like the famous XOR operation. With XOR, drawing a second time the same bitmap actually erases it and restores the previous state. That's what I would like to do, but unfortunately no such modes exist in Gdi+ (or I missed them?). I know that I can switch to Gdi API with a Graphic::GetHDC(), but then how can I replace Graphic:awImage() with Gdi before ReleaseHDC()?

1.3 - Main issue with these overlay drawings: randomly, display starts to flicker quickly between the 2 gauge display. By chance I found a strange workaround which is the following:

• I open the 2D version of the Q400 glass cockpit I use (FO MDU) and reduce it at its minimum size so I don't see it much
  
• When the 3D gauge starts to flicker, I just resize the 2D window ( 1 pixel is enough) and flickering stops instantly!

Can someone explain this behaviour?
​

It helps, but is quite boring as you can imagine. But this behavior makes me think that there is perhaps a solution.

I don't find SDK documentation related to the friend macros of SET_OFF_SCREEN like GET_ON_SCREEN and others.
Did someone experiment playing with them?

Other observation, VC gauge declaration order has an effect inside a single [Vcockpit] section: if I declare my gauge before the original one (gauge00), it flickers 100% of the time and the previous workaround has no effect.

See a dev version sample of the "cone only drawing" in the FO main DU of Q400 VC:

2. knob capture

2.1 - I'm able to read the Q400 Wx Tilt/mode/gain values through LVars. However I have a problem with the FO range knob.
This call (PED_FO_RANGE_KNOB) always fails. I request LVars ID's during POST_INSTALL callback. Other Wx LVars request succeed, but all FO pedestral calls fails. I don't understand why. I tried also the get ID's during first callback in 18Hz clock and it has failed also. I'm able to capture the PED_CPT_RANGE_KNOB (Captain side) ...

I checked that PED_FO_RANGE_KNOB status is correctly captured by LINDA.
Is it possible that some FO LVars are created after my gauge?


2.2 - All LVars values are returned in FLOAT64, but how can we know the unit used to convert them properly?

Thanks for reading so far

Roland

 

[Dutch]

I might be able to help you a bit, since grabbing add-on Lvars for our own purposes is a black art we've gotten a grip on with FSCaptain.

How do you mean it fails? Always returns zero?

And how are you getting the Lvar values? We use execute_calculator_code("(L:CabinPressureVar,number)",&ReportedPressure,NULL,NULL); for example.

Doing it this way you don't have to worry about registering Ids or anything like that. Just put the statement in wherever you want to read the value. If it doesn't exist it returns zero. No possibility of failing.

Dutch

 

[roland_lfor]

Hello Dutch,

I don't use execute_calculator_code() but the following in a single method:

mstWxPars.pTilt = check_named_variable("PED_WR_TILT");
mstWxPars.pGain = check_named_variable("PED_WR_GAIN");
mstWxPars.pRange= check_named_variable("PED_FO_RANGE_KNOB");
mstWxPars.pMode = check_named_variable("PED_WR_MODE");

pTilt, pGain, pMode are filled with valid IDs, but pRange = -1.

I will try with execute_calculator_code(), but I don't see any reason that makes third call invalid.

Thanks

Roland

 

[ddawson]

...
I checked that PED_FO_RANGE_KNOB status is correctly captured by LINDA.
Is it possible that some FO LVars are created after my gauge?
...
Roland

Yes, this is very possible.

 

[Dutch]

Doug is very right, and that's why execute_calculator_code is better. Since you don't have to register anything just check for it, then whenever it appears you will catch it if the execute_calculator_code is in your main loop. We do that all the time because we face the same problem - Lvars that aren't there when we first initialize.'

Also if you're wondering, execute_calculator_code is very fast, it has no measurable effect on frame rate and we use it dozens of times per loop.

An Lvar doesn't exist until it's referenced. The panel may be not creating this one until the pilot actually moves that knob. But again execute_calculator_code doesn't care - it will return zero and create the Lvar because you referenced it. If the pilot moves the knob, it will become non-zero.

 

[roland_lfor]

Thanks

I tried this code in PANEL_SERVICE_PRE_UPDATE callback and it always return 0.0 even when the knob is turned:

FLOAT64 val;
execute_calculator_code("(LED_FO_RANGE_KNOB, number)", &val, NULL, NULL);

Can you believe it? What can be wrong?

 

[Dutch]

That code looks right, it should pick up any value of that Lvar no matter what it is. Very strange. Yet when you look at it in LINDA it's non-zero?

Look carefully at it to be sure there's no tiny misspelling or typo. Baffling.

 

[ddawson]

This block of code will give you all of the currently existing LVars.
It might not be your typo...

void EnumerateLVars()
{
int iID = 0;
char sID[6] = {0};
PCSTRINGZ pcsName = 0;
while (TRUE)
{
pcsName = get_name_of_named_variable(iID);
_itoa_s(iID,sID,10);
WritePrivateProfileString("LVars",sID,pcsName,"./lvars.txt");
if (strlen(pcsName) == 0) break;
iID++;
}
}

 

[n4gix]

This block of code will give you all of the currently existing LVars.
It might not be your typo...

Boy, that's for sure. I once ran into an instance where the variable was supposed to be this (pseudo example):

(L:SOME_STRING_NAME,enum)

- but was actually -

(L: SOME_STRING_NAME,enum)

 

[roland_lfor]

Doug, thanks for the code.

I enumerated Q400 LVars with your function, found as expected my "PED_FO_RANGE_KNOB" @ id 165, no space before.
This LVar already exists during PANEL_PRE_INSTALL callback when I check the aircraft type loaded, it's not a "delayed" declaration issue.

If I use directly ID 165, I'm able to read knob value, however my ID request through check_named_variable() still fails.
Who can find an explanation

Actually all "PED_FO_xxx" LVars ID requests fail... but "PED_CPT_xxx" succeed.

Roland