• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA GDI+ Transparency

M

MacFarland Masterton

Messages
65
Country
us-massachusetts
Hi folks. You guys are always wonderful and have helped me out a lot in the past. Here's my current issue:

I'm designing my first GDI+ gauge, it's a gunsight. For now, it's on a 2D panel.

I followed pretty closely the Microsoft sample code for the "transparent gauge." So far so good, I draw the objects that I need, and when I vary transparency through the KEY_VIEW_PANEL_ALPHA_SET it works perfectly, from fully opaque to fully transparent, eventually disappearing altogether.

The problem is this:
I should very much like to vary the transparency of the various GDI+ objects directly, ie through their respective brushes and pens. But when I vary the alpha value of a brush, the result is not what I would expect:

The actual transparency of the object does not change at all, it remains at exactly the value set through KEY_VIEW_PANEL_ALPHA_SET, but as I decrease the brush alpha, the object's color changes from white (the brush color) to a dark gray, and then abruptly disappears at 50% alpha (128) and is entirely invisible at any value which is below this.


Am I describing a familiar problem? My assumption is that FSX would like the brush alpha channel to be in a different format than what the brush is providing... Is it something that is fixable? I would ever so much appreciate any sort of guidance.

Hopefully,
Farley

P.S. My "MAKE_STATIC" code appears below, on the off-chance that it is significant. I am using the background bitmap from the Microsoft sample gauge.

MAKE_STATIC(migDummybackground,BMP_BACKGROUND, NULL, NULL, IMAGE_CREATE_DIBSECTION | IMAGE_USE_TRANSPARENCY | IMAGE_USE_ALPHA | IMAGE_USE_ERASE | IMAGE_ERASE_ALWAYS, 0, 0, 0)
 
Yep. I had this problem when I was working on the Milviz F-86 gunsight. The problem is not in your gauge or your code. If you were to draw a black background you would see your alpha channels having the desired effect but only between the black background and the element being rendered. You need to go into the material settings in the model file and change the blend setting from SrcAlpha/InvSrcAlpha to SrcColor/InvSrcColor.
 
Aaaah. Got it. Thank you so very much! Yes, I did notice that when I removed the "use transparency" flag, revealing the black background bitmap, the brush alpha worked with it.

So am I correct now in thinking that, while it will work properly once I receive the VC model (with correct materials), I can't really get ahead of the curve by testing it in a separate 2D panel? Is there a way to change the appropriate setting in panel.cfg or something? I tried slapping my gauge on the $reticle texture of the A2A mustang just now - it's not showing up at all, so I figure I'm doing something wrong with gauge dimensions or the like. I'll keep at it.

Thanks!!
Farley
 
Oh, hi Bjoern! I forget when it was that I last mentioned it. But, since you asked and I love to talk about it...

What happened is it morphed into something with a much larger scope. The parts I have working at the moment are the four-course range and radiobeacons/NDBs (both MCW and CW) with voice and code weather broadcasts, fan and station marker beacons, a few commercial AM radio stations (at the moment they only play some audio files stored on my computer), ZB/YG/YE equipment (shore-based and ship-board - any type of station can be placed on an AI vehicle). The navaid database covers 100% of the continental US and southern Canada as of March 1944, and all allied installations (not including RACONs) in the central/southern pacific and SWPA as of January 1945. All stations operate only within their published hours. I've also implemented HF and VHF communications using Microsoft SAPI recognition/TTS. Some of the continental range stations can provide wx for themselves or other stations, and can activate "on request" navaids. In the Pacific, I've added all the control towers, but they currently are only capable of some extremely rudimentary ATC functions, and of course I'm hampered by the fact that most of the airfields no longer exist and are not present in the scenery :rotfl:. So it's got a long way to go. The application GUI and the airplane config file setup are extremely buggy, and I only have a couple of very basic xml gauges to control the radios. I mainly fly the A2A warbirds, which have decent animated models of appropriate radios in the VC, so I can hijack their knobs and such. The physics side of it has been fun to develop too, the algorithms currently factor in Tx power, Rx sensitivity and tuning, wavelength, range, altitude, atmospheric conditions, time of day/ionosphere, polarization and directional gain of the two antennae, and of course everything is suitably dithered and randomized. In addition, within the receiver side of it there's some fun stuff, for instance a heterodyne mixer which factors in all the different received RF signals and produces the appropriate difference tones when they are within the audible range (This is how simultaneous range/voice stations worked, the range towers transmitted unmodulated on the published freq minus 1020hz, effectively creating a SSB tone modulation in the receiver when combined with the central tower which transmitted on the published frequency with AM voice modulation. I really think it's utterly fascinating!). So the BFO is implemented in the receiver simply by injecting its frequency into the mixer. Admittedly, the BFO doesn't sound great yet - because the tuning knob moves in small jumps, the BFO tone jumps immediately to a different pitch, rather than changing smoothly. I have yet to find a way to work around that.

So that's about the state of it at the moment. My dream is to develop it payware and use essentially the same business model as VRS TacPack. Airplane developers would ensure compatibility and/or modify/drop in animated and compatible 3D radio models provided by me, and users would then (hopefully) purchase the module to use the extended capabilities. Of course, there's no reason at all why the same physics and audio engine couldn't work just as easily with modern radio equipment. And in a modern environment, the program could conceivably provide other goodies. For instance the database could be built automatically from Navigraph data, perhaps I could even interpret and apply current NOTAMS relating to navaid serviceability? And of course, it would be pretty cool (and probably achievable) to be able to tune the ADF to an AM broadcast transmitter, and hear the station's live web feed come through your headphones while you home in on it. In any case, the next major order of business that I can see ahead is to build new application and in-sim GUIs, especially a "cheater map" which will overlay my database over the gps terrain and airports.


****************

All of that said, the whole thing is on hold for right now. I recently was hired by a small sim-aircraft startup as a C++ programmer to write gauges and guts (one of them being the actual subject of this post). I figure I stand to learn a whole lot from working inside a startup company that is in many ways very similar to the one that I wish to eventually start. I'm discovering a lot about how such businesses operate, how the Add-on industry works, how to develop a software product in a team setting, etc., not to mention learning new programming skills. So I think it's the correct direction for me to focus the software side of my life for the time being. And on top of that - I find the work highly enjoyable. I love poring over old aircraft tech manuals and obsessing over each detail - I've been doing it for fun from a very young age - my development team is great and easy to work with and get along with, and at the moment I feel totally confident that our current plane is going to end up being, like, the best add-on airplane ever. :D

Anyway, that's basically it.

Warmest greetings,
Farley
 
hehe, I should certainly expect nothing less than heresy from you! :rolleyes: I'm still a long way away from actually releasing this as my dream product, so I'm definitely not in any way opposed to uploading the range part by itself in the meantime. But it'll take a bit of time to separate it out, test it on its own, consolidate all the various bits into a package, and maybe even make some kind of installer. I'll also need to scan the facilities charts, as they're on paper, and the program would be pretty useless for flying without them. I don't have a whole lot of time at present, but I will keep it in mind and try to do it on a proverbial rainy day.

Sincerely,
Farley
 
You must log in or register to reply here.
Back
Top