Hi,

 

Do you have a picture of the real thing?

 

 

Sure, this is from slightly earlier in time than the one I'm modeling, the base color of the unit is hence much darker than later units:

 

 

 

 

 

 

 

Today I spent experimenting a lot more with the Alpha channel. I have now I think a good methodology, this has the outer bezel ring and the pitch rings as part of the alpha bitmap. This covers all the jaggies nicely without changing the overall look by adding an area of shadow.

 

I was playing about with it and created an old crusty looking version of the gauge with glass that needed a good clean! Tomorrow I will work more towards producing a crisper version. Effectively the rings are going to be treated as semi-transparent by the Alpha layer, the main glass as transparent, which will I hope give me good looking pitch rings and also a clear version of the black and white display of the roller blind.

 

Definitely addictive, but also for me at the moment a very long iterative process of seeing the effects of things. I've dabbled about with all sorts in FSX the last few weeks, but gauges are definitely the biggest challenge so far. They are also the most rewarding for me though too. It's a good job I have you guys to help me out, as really I would have given up with it all by now otherwise. (Who would have ever guessed what was involved in the Alpha channel, I tried days ago with DTXBmp to put in an alpha and when it wouldn't work I just assumed it couldn't be done :blush:)

Latest version as it appears in FSX:

 

 

 

I still can't quite make it perfect, but very pleased with this now.

 

I never did get to the bottom of the banding problem, this version also changes color when it is re-sized and shows some different graphic glitches such a purple vertical lines at some sizes. I really can't think of anything else to try to get around the glitching and banding.

 

I tried opening bitmaps from standard and third party gauges on my system then re-saving in every mode and format possible, and it seems to generate the exact same problem. I've tried saving both directly from Photoshop and Image Tool as 24 bit, 8 bit, RGB, Indexed... it seems to make no difference, they look great on my monitor, but as soon as they open in FSX as a gauge, awful :(

 

Still in all it is my first go at this so I think for now I'll declare the graphics finished. I'm going to look again over the xml for this one, and add the Flight Director Bead (white ring held by cross-hairs in picture of actual gauge) and then move on to next gauge. For now the FD bead will just indicate the difference between actual heading and selected heading, which was one of its function in the real instrument.

You might try applying a bit of "gaussian blur" and/or "motion blur" to the image in Photoshop before saving. This has in the past helped to mitigate or even eliminate the gradient banding.

 

http://www.flightsim...radient-Banding

You might try applying a bit of "gaussian blur" and/or "motion blur" to the image in Photoshop before saving. This has in the past helped to mitigate or even eliminate the gradient banding.

 

http://www.flightsim...radient-Banding

 

Ah, thanks I'll try that. I did a 'smudge' on some areas yesterday and for sure it looked better than if I hadn't.

 

Video of it doing its thing including a spin recovery:

 

 

PS apologies for adding music for some reason sound was not recording. (music is my own original work)

Things were going well - now I'm stuck again!

 

It seems simple, a flight director bead deflects to the left or right to show the deviation of selected course and actual heading, so I came up with:

 

 

Shift>

<Value Minimum="-50" Maximum="50">(A:Autopilot Heading Lock DIR, degrees) (A:Heading Indicator, radians) rddg - </Value>

<Scale X="3.6"/>

<Delay DegreesPerSecond="40"/>

</Shift>

 

Which works.... ....sometimes.

 

There is though a problem, the code works fine for say a selected course of 230 degrees and a heading of 250 degrees, it figures out the difference is -20 and moves the FD bead accordingly across the face of the instrument to the left. (It's constrained at -50 and +50 because I would imagine it would park just at the edge of the instrument window as the deviation increased beyond the amount that could be displayed on the instrument)

 

I guess a lot of people are seeing the problem already, it works until you get around to Northerly headings, then the jump from 1 to 360 completely messes up the maths.

 

Any thoughts on this? I get the maths but I'm really stuck with the solution in XML as I've only just started out with it and though I have some ideas of how it might be solved I don't have much clue how to code them.

 

It would be nice too if there was a way that the +ve or -ve sign of 'Value' changed at the reciprocal heading of the Autopilot Heading, instead of when passing through North. This would then force the bead to 'switch' from left to right at the right time to indicate the correct direction to turn in. Now it only switches sides when the actual heading passes through North.

This should work. Taken from a previous project I did.

 

<Value Minimum="-50" Maximum="50">
(A:Autopilot Heading Lock DIR, degrees) (A:Plane Heading Degrees Gyro,degrees) - dnor s12 180 > l12 360 < and if{ l12 360 - } els{ l12 }
</Value>

 

The above code was written a long time ago w/o the knowledge of the rng function (if in range) so written now it may look like ( not tested, logically the same thing ) -

 

<Value Minimum="-50" Maximum="50">
180 360 (A:Autopilot Heading Lock DIR, degrees) (A:Plane Heading Degrees Gyro,degrees) - dnor sp12 rng if{ l12 360 - } els{ l12 }
</Value>

 

Of course if wanted, replace (A:Plane Heading Degrees Gyro,degrees) with (A:Heading Indicator, degrees)

 

Ex. 1

AP heading = 50

Current heading = 300

Subtraction and DNOR = 110 , It is NOT in range of 180-360 so turn right 110* but limit to 50*

 

Ex. 2

AP heading = 300

Current heading = 50

Subtraction and DNOR = 250 , It IS in range of 180-360 so subtract 360 = -110* (left turn) but limit to -50*

 

BTW if unknown - The l12, sp12, s12 are temporary registers @ register 12 ( 0 - 39 are available ) , s =store into , sp = store into but remove from stack (pop) & l = load from.

 

I hope this may help.

Roman

This should work. Taken from a previous project I did.

 

<Value Minimum="-50" Maximum="50">
(A:Autopilot Heading Lock DIR, degrees) (A:Plane Heading Degrees Gyro,degrees) - dnor s12 180 > l12 360 < and if{ l12 360 - } els{ l12 }
</Value>

 

The above code was written a long time ago w/o the knowledge of the rng function (if in range) so written now it may look like ( not tested, logically the same thing ) -

 

<Value Minimum="-50" Maximum="50">
180 360 (A:Autopilot Heading Lock DIR, degrees) (A:Plane Heading Degrees Gyro,degrees) - dnor sp12 rng if{ l12 360 - } els{ l12 }
</Value>

 

Of course if wanted, replace (A:Plane Heading Degrees Gyro,degrees) with (A:Heading Indicator, degrees)

 

Ex. 1

AP heading = 50

Current heading = 300

Subtraction and DNOR = 110 , It is NOT in range of 180-360 so turn right 110* but limit to 50*

 

Ex. 2

AP heading = 300

Current heading = 50

Subtraction and DNOR = 250 , It IS in range of 180-360 so subtract 360 = -110* (left turn) but limit to -50*

 

BTW if unknown - The l12, sp12, s12 are temporary registers @ register 12 ( 0 - 39 are available ) , s =store into , sp = store into but remove from stack (pop) & l = load from.

 

I hope this may help.

Roman

 

I've just test flown the first example code, which works perfectly. :biggrin:

 

Many thanks also for taking the time to explain how it is working, I feel like I just made a big big leap in understanding how to work with xml. I had done similar calculations in excel before so it was slowly driving me completely nuts not knowing where to start in xml.

 

That's my first gauge pretty much done, though I think all the credit has to go to all those that have helped me along the way. :smile:

Piggles,

 

Glad it worked for you. Welcome to the addictive hobby of gauge programming. :blink:

 

BTW - a big fan of the Muppets. Like the avatar! LOL

 

Roman

I wish now that I'd archived those images from Susan's blog so that they would still appear. Ah, the lessons one learns over the years... :blush:

I never thought of using the alpha channel in my first post because it isn't supposed to work with anything except MAKE_STATIC... but it does. You will get limited success with MAKE_NEEDLE and MAKE_SPRITE (which is possibly what Gemma is using?) and good success with MAKE_ICON.

 

Anyway, as it happens the 'Adding Alpha Channels' section in sd2gau31 contains a set of how-to-do-it images. They're for an ADI indicator rather than the checkerboard that Susan used but as that section is purely about creating the alpha channel, it will be helpful for both C and XML programmers. You may want to pull the section out as a possible separate tutorial?

 

-Dai

Hi Dai,

 

I've not made use of MAKE_NEEDLE, SPRITE or ICON (as I don't know what they are!)

 

What I have are bitmap images laid one over the other each using the same mask bitmap.

 

The final layer is now what started as the canvas image, but brought to the top with an alpha channel applied to make it totally opaque for the blue painted body and bezel ring, semi transparent for the rings and transparent in areas of the clear window.

 

I'm now wondering if there was any need at all for using a canvas and mask images (I was just following a tutorial at the time and did as it said), as I figure it I could have not used either, as the function of the mask image was to punch a hole through the canvas.. I could have just made parts of each bitmap 0,0,0 and hence invisible and then just laid the alpha bitmap on top of the lot of them... hmmm something to think about in the New Year as I must now reluctantly drag myself away from gauge creation and concentrate on friends and family for a few days!

 

edited to correct where I said 'transparent' but meant opaque.

 

I should also add a big MERRY CHRISTMAS! to all my new friends helping me out with FSX!

Hi Dai,

 

I've not made use of MAKE_NEEDLE, SPRITE or ICON (as I don't know what they are!)

Dai is speaking in "C gauge" terms, so don't let this distract you from XML speak...

 

There are two methods for creating gauges for FS, one using compiled "C" language code, and the other using XML scripts.

 

If you've ever looked closely at the FSX SDK, especially the key events section, you may have noticed that almost all the commands have two versions. The leftmost column are the "C code" versions, the middle column are the XML versions, and the rightmost column is the semi-comprehensible "explanation" for them...

 

Anyway, as it happens the 'Adding Alpha Channels' section in sd2gau31 contains a set of how-to-do-it images. They're for an ADI indicator rather than the checkerboard that Susan used but as that section is purely about creating the alpha channel, it will be helpful for both C and XML programmers. You may want to pull the section out as a possible separate tutorial?

 

-Dai

Dai, I'll have to take a closer look after the holidays. That may just be what I'll do then, with full attribution as to the source of course. B)

A last question:

 

Should you take into account in the code a form of windcorrection?

 

 

...and from the Netherlands: Merry Christmas and a Happy New Year!

A last question:

 

Should you take into account in the code a form of windcorrection?

 

 

...and from the Netherlands: Merry Christmas and a Happy New Year!

 

 

I've escaped the mince pies and shopping for five minutes! That is an interesting question, I am researching how the Flight Director system functioned still. The Aircrew manual AP 101B-1003 only mentions the horizontal movement of the FD displaying the difference between selected heading (on the nav unit) and actual heading, which the code models perfectly.

 

How sophisticated the unit was regarding wind corrections, I do not yet know, it is possible there was no built-in wind correction as the interceptor was ground controlled and the corrections may have been made by the ground controller. Or wind correction was calculated by the pilot and the course bearing selected accordingly for general navigation.

 

I'm told the main original function of the Flight Director was to facilitate a Mach 0.89 climb (max fuel efficiency for climb to operating altitude). That also would be interesting to model but with many factors to consider, such as changing air density and changing aircraft weight during the climb it would be some time before I could attempt to model this.

And nobody ever did find out just how fast it would go in level flight...

Hope everyone had a great Christmas!

 

I'm back to thinking about the coding for this instrument.

 

I've been doing more research and the main functions of pitch and roll indications were controlled by data sent from a Master Reference Gyro (MRG).

 

The MRG could not topple.

 

With the current code FSX will allow the instrument to topple (which it physically could not do). Also on 'run down' the horizon tilts, then slowly 'slips down'.

 

 

The real instrument would tilt when off, but the black/white display would have remained centered (as illustrated in the picture of the real instrument on the previous page), without moving down the face of the instrument:

 

 

What are the options to remove the toppling and modify the run down sequence? As these appear pre-modeled in FSX when using the following variables:

 

<Shift>
<Value Minimum="-90" Maximum="90">(A:Attitude indicator pitch degrees, degrees) /-/</Value>
<Scale Y="1.8"/>
</Shift>

<Rotate>
<Value>(A:Attitude indicator bank degrees, radians)</Value>
</Rotate>

 

 

 

Another interesting aspect of the real instrument is that on start up the horizon display would rotate for approximately 50 seconds whilst the MRG spun-up, again my xml knowledge is limited but some pointers on how I might model the correct start-up and run down sequence and remove the toppling in flight would be appreciated.

 

Also are there any good books or web tutorials on xml relevant to gauge programming? The usual advice seems to be to look at existing gauges, which I've been doing, but it's a difficult process with my current very limited knowledge of xml to glean much from doing that. My main resource so far has been the ESP web page on xml gauges.