Stubborn compass tape in a hud

[Guest ridgell]

i am wanting the compass tape to rotate with the horizon-line,used; (A:PLANE HEADING DEGREES MAGNETIC, Degrees)(A:PLANE BANK DEGREES,radians) but the tape inverts and does not rotate at all.why? same routine rotates every other component of the hud.(without the rotate the tape behaves well, but...)

[Guest Patrick_Waugh]

Have you tried removing the mask to see what is going on?Not sure, but maybe you can't rotate the mask in this way. Could also try puting the mask and image in separate elements.

[Guest ridgell]

i do not believe it is the mask.the mask is round ( like the real projection area of a hud) i am rotating the vertical items ( the pitch ladder) useing the same mask.my pitch ladder is to scale meaning it shows 10 degrees of pitch at 10 degrees up vs the fs9 world. i had to break up the pitch ladder into 3 parts to accomodate such a huge vertical picture. a trick i learned from 'jprintz' who made a beautiful f-18 hud.i was (in the code above) trying to rotate a 2000 bit picture.but since it is shifted before it is rotated the axis points are screwy.it rotates fine if i the shift part. after messing with it some more i have decided to make the compass to scale, that will require breaking it up into 3 pieces as well. then rather then use item value= i will use a scale X = .that is the method i used to manage the pitch ladder which is shifted to accomodate pitch, shifted again to accomodate alpha & beta, AND then rotated. im hoping that will work. but first i have to redraw the compass tape. if it does not ill pull a 'schwarzenegger' (i'll be back)

[Guest Patrick_Waugh]

>i do not believe it is the mask.>the mask is round ( like the real projection area of a hud) >i am rotating the vertical items ( the pitch ladder) useing>the same mask.I don't either, but removing it would let you see all of the tape, but I have figured out your problem below.>my pitch ladder is to scale meaning it shows 10 degrees of>pitch at 10 degrees up vs the fs9 world. i had to break up the>pitch ladder into 3 parts to accomodate such a huge vertical>picture. a trick i learned from 'jprintz' who made a beautiful>f-18 hud.>>i was (in the code above) trying to rotate a 2000 bit>picture.>but since it is shifted before it is rotated the axis points>are screwy.>it rotates fine if i the shift part.There's your problem, you have exceeded the limits for the size of the BMP. There is no need to have such a big BMP, as the distance between your scale lines on the tape, can be any distance you define apart, and then you scale the FS variable to meet your scale. To have such a big BMP just creates more work for FS, and slows your sim unnecessarily. In this case it will not even work.> after messing with it some more i have decided to make the>compass to scale, that will require breaking it up into 3>pieces as well. then rather then use item value= i will use a>scale X = .Bad plan. Use the smallest bmp's you can to maximize performance.>that is the method i used to manage the pitch ladder which is>shifted to accomodate pitch, shifted again to accomodate alpha>& beta, AND then rotated. im hoping that will work. but first>i have to redraw the compass tape. if it does not ill pull a>'schwarzenegger' (i'll be back) Good luck

[phjvh 0]

Hi,I tried .bmp's too, but didn't succeed.Now i use text only and that works ok.There is already somewhere here an older discussion.Jan"Beatus ille qui procul negotiis..."

[Guest ridgell]

sigh ! the hud guru himself says it can not be done. jan, do you have a method for makeing the string track?if i just use strings in a static place where the numbers change to reflect headings it looks 'cheezy' seems 'without having tried' that you would encounter the same axis problem string or bitmap.

[Guest ridgell]

PATRICKyour belief is certainly the predominant one.most HUDs are actually transparent attitude indicators.the first scaled HUD i came across was by jprintz,the coding was very complex, and he did not use registers or macros. he also coded to keep the horizon on the horizon at all altitudes. which is not accurate. at 30000ft the horizon is 500+ miles away and undiscernible.i threw snipets of his coding up in the forum looking for shorter versions. his HUD was a stand alone cockpit.(no cockpit). he was less then thrilled at having his work critiqued by some of the code gurus, but in spite of all that. his scaled HUD was BEAUTIFUL!i can not go back. the spatial reality increase from a HUD in scale is pretty impressive. the tree or bridge under the -005 pitch line is still on the -005 pitch line when you push the nose on it, or the house 15' port is still 15' port when you jink over. even if you have to leave off many of the bells and whistles and stick to basic components. he also wrote a really nice premier in the manual for his HUD. for those of use who are ?technically challenged? or who work more from diligence then skill or programming ability would do well to read it. he gets very detailed about the visual references of fs9. and how most cockpits are (and look) just pasted onto the screen without regard to scale. my $00.02

[Guest jprintz]

Hi ridgell. Sound like maybe you're trying to do an A-320 HUD or something like that, where the heading tape IS the horizon line? That's going to be a complex series of shifts and rotates, which I have never tried, but i'm certain it's possible, because some French team did it. The heading degrees were almost but not entirely to scale, also. It was really very nice work. (I'll just have to try to remember where it was that I saw it!) It was not XML though, so even if I can ultimately point you to it there's no way to get hints from the code.About your horizon and all the shifts and rotates necessary... keep hammering away. There is a waypoint "tadpole" in my F-16 HUD which took something like 9 or 10 shifts / rotates to get it even close to its action in reality. (It floats around with the vector (3 operations, or elements), shifts across it based on bearing to waypoint (1 op.), rotates to point to the waypoint (1 op.), and, finally, it's always in a position where a line between it and the vector is parallel to the horizon (that's 2 more trig ops). And then... some of those shifts and rotates have to be undone. (2 or 3 more ops.) Crazy. And it is still not entirely correct! My point with all of that: you'd be surprised at what can be done with a little experimentation (i.e., pulling of hair ;-) ... and the order of those shifts and rotates is (obviously) extremely important, and what I had to tinker with the most. Oh, and the horizon shifting with altitude thing... this is difficult to explain in detail, but i'll try, because i've been exactly where you are with it. First, the amount of shifting is done by the "guts" of the sim, not HUD code. The HUD is focussed at infinity, and the HUD horizon (as I know you know)just demarcates the point of level flight. Naturally then it shifts up with altitude. The extent of the shift... well, I measured this once and the extent to which it's shifted up in the sim was like 1.4 times the amount in reality or something like that... (5 degrees at 30K feet, as I recall?). But againb, the extent to which it does shift up with altitude is set by the sim, not HUD code. And I for one would be VERY hesitant to mess with that operation. (I once did anyway. ;-) Why the hesitation now? Well.... your longitudinal axis must always be at the same point on the screen, as must your waterline, since only rebuilding the aircraft in flight could change them (heheh)... and 1 degree worth of pitch is always the same, no matter the altitude... as is 1 degree worth of vector displacement... so, since it's not just the HUD horizon but the sim's internal longitudinal axis that's shifting up with altitude (that's the important part), it's pretty easy to see how artificially messing with that HUD horizon shift throws off the balance and relationship between those 3 things - axis, pitch, flight path. (And I consider those to be the most fundamental things in a HUD.)I do know exactly what you're talking about and the problem you wish to overcome, only because it annoyed the #### out of me for awhile and I tried to "fix" it once, but I soon realized there was no way to do so without ultimately fudging on either axis position, pitch ladder displacement WRT the real axis, or vector displacement WRT the real axis... all very bad things, IMHO!!Anyway, good luck with your horizon / heading tape. I'll try to dig up where it was I saw that Airbus HUD. Thanks for the kind words too, and ####, don't ever feel like you're "critiquing." Seriously. 90 percent of us on here are amateurs who do this stuff part time, for fun, so how seriously can it be taken? I for one have plenty of other things to take way more seriously. ;-)Scott

[taguilo 33]

Ridgell,The size of the bitmap shouldn't be a factor.Did you try shifting with (A:PLANE HEADING DEGREES MAGNETIC, Degrees) dnorOr using with instead of ?Tom

[Guest ridgell]

minus the dnor that is what i used.like i said it rotates like a champ without the shift.so it is not the size.it has got to be the axis. unless it is the mask that rotates and only the image contained within. if i am at the edge of the tape and the axis is set up for the midline...it would be like a needle on a regular gauge. i went through a LOT of trouble to get the pitch in scale, i was using the CustomDraw Name="fs9gps:rose to give the HUD a different look. i am doing a saab Viggen cockpit. the Swedes have a foot in both Warsaw and NATO standards...gauges spin backwards with zero at the bottom. having never seen a Viggen HUD i created a cross between a French mirage HUD and made up the rest...year later i find a video of a Viggen HUD! and back to the drawing board i went. after my initial failure, & all hope of a 5 minute fix out the window, i decided to scale the compass. a degree is a degree and i had the scale worked out on the pitch ladder. to my thinking it should work the same as the pitch later. Just finished the 1st set in light color

[Guest jprintz]

At the risk of stirring up a hornet's nest, I would say don't worry so much about vectors vs. bitmaps, quite frankly. I did a basic vector HUD (ladder, vector, compass), and while there is a very nice crispness to the pitch ladder lines, the one BIG benefit which I somehow assumed vectors would bring (elimination of the dark jagged edges which appear on some symbology and text) was nowhere to be found. (My fault for assuming I suppose!) And the BIG downside to vectors is that, if you're modeling a real-life, "busier" type of HUD, and you're trying to make it REALLY look like the real one, you can get a type of authenticity with bitmaps that you're extremely unlikely to get with vector drawings (at least without some SERIOUSLY dedicated effort... and I do mean really massive investments of time). Take the F-16 HUD pic I've attached, for example... I contemplated doing my F-16 HUD with vectors, but... do you know how many vector drawing elements that would take, even considering the blatantly obvious shortcuts? A TON. One for each dash in each of the altitude, heading and airspeed tapes, to start. Then for the dashed and slanted negative pitch ladder (where each rung has a different slope)... forget about it. Absolutely nightmarish. Just to be clear though, there's no denying the benefits in crispness that vector drawings bring, and for a less involved HUD (or even the main horizon line and some of the pitch ladder lines in a busier one), I would not hesitate to use them. But for something really involved, for me (at last until vectors get rid of those dark jaggies -- any chance of this in FSX???), their benefits just do not outweight the cost, IMO.And now, let the flaming commence.... ;-)

[phjvh 0]

Hi,You are right about the not optimal look of the cifers, but they pitch, shift and rotate as they should.I don't have the code available here, but it looks like:"heading" code 10 -important!valuescompassbankthe limits,"mask""heading" code important!valuescompassbankthe limits,"mask""heading" code 10 +important!valuescompassbankthe limits,"mask"pitchy=".."Jan"Beatus ille qui procul negotiis..."

[Guest Patrick_Waugh]

You misunderstand my post.You can have what you are calling "correct scale" without having to have the bmp any particular size.For example, my attitude heading reference system lines up 1 for 1 with the pitch and bank. You bank 5 or 10 degrees, and you'll see you line up with the 5 or 10 degree marks that are at exactly that angle off plumb. Same with pitch.The distance between pitch lines is completely arbitrary, and up to you. You just move the tape as far as you need per degree. If you want to do 1:1, then you have to use bigger bmp's, or smaller instruments. Since you are doing a HUD which amounts to a large instrument, I'd use a larger scale, and that way I could use a smaller bmp.Just my .02 cents.

[Varmint007 2]

>The distance between pitch lines is completely arbitrary, and>up to you. You just move the tape as far as you need per>degree. If you want to do 1:1, then you have to use bigger>bmp's, or smaller instruments. Since you are doing a HUD>which amounts to a large instrument, I'd use a larger scale,>and that way I could use a smaller bmp.Well, actually that's not true; The distance between pitch lines is only "arbitrary" on incorrectly modeled HUDs. Each pitch line should represent exactly the angular section of sky it's labeled for. i.e. 5 degree pitch lines should represent 5 degrees of FS "sky" each, and therefore be a specific number of pixels apart. This is how real HUDs are modeled. Simply scaling the translation so some arbitrarily spaced lines are correct when 0 degrees is level and 90 degrees is vertical is not correctly modeling a HUD as these separations will no longer represent correct angles. Pitch lines are used to correlate to velocity vectors, target symbology and many other elements which directly relate to the outside world.--Jon

[Guest Patrick_Waugh]

>>>The distance between pitch lines is completely arbitrary,>and>>up to you. You just move the tape as far as you need per>>degree. If you want to do 1:1, then you have to use bigger>>bmp's, or smaller instruments. Since you are doing a HUD>>which amounts to a large instrument, I'd use a larger scale,>>and that way I could use a smaller bmp.>>>Well, actually that's not true; The distance between pitch>lines is only "arbitrary" on incorrectly modeled HUDs. Each>pitch line should represent exactly the angular section of sky>it's labeled for. i.e. 5 degree pitch lines should represent 5>degrees of FS "sky" each, and therefore be a specific number>of pixels apart. This is how real HUDs are modeled. Simply>scaling the translation so some arbitrarily spaced lines are>correct when 0 degrees is level and 90 degrees is vertical is>not correctly modeling a HUD as these separations will no>longer represent correct angles. Pitch lines are used to>correlate to velocity vectors, target symbology and many other>elements which directly relate to the outside world.>>--JonJon,It is simple math, and you have reified one scale is all. See you are thinking the arc length is from the CG of the aircraft. What you forget is the real center is the gyro. So the arc length the distance measures is really from the center of the gyro in any case. It is measuring degrees of rotation.Imagine that I surround your aircraft with a large transparent ball, and mark off your degrees of "sky" for you. That would unwrap to one size of bmp.Now imagine I double, or half the size of the ball. The bmp would double, or half, but the angle measured is the same.Same principle. The distance between the lines on each of those balls is going to be very different, but measure the same arc.So, why use twice the size ball, when you get the same effect. In other works, there would be no apparent difference to you in the cockpit.Patrick