Sign in to follow this  
Guest jprintz

xml trig help plzzzzz

Recommended Posts

in XML, how would i write;x=r*cos bwhere r=(A:INCIDENCE ALPHA, degrees) b=(A:Attitude indicator bank degrees,degrees)for a hud, where pitch ladder's 'x' matches the AOA's 'X' position through rotation( if radians is easier thats fine, so long as i can scale it to 25 pixels per degree )

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

x=r*cos b would be:r b cos * (stack is now r * cos(:( )But I guess I'm confused as to why you need trig for what you're trying to do? Aren't you just trying to shift the pitch ladder with beta to follow the VV?Here's one for you that's been killing me:I assume you're familiar with the HSI on the F/A-18. Any idea how to do the course line arrow? It needs to pivot about the tip for the OBS, and rotate around the circumference of the rose so as to always intersect the current VOR/Waypoint plot if it's within the bounds of the rose.The trig is just eluding me:/--Jon

Share this post


Link to post
Share on other sites

hmm, i am not much of a programmer, i have no idea how to use the stack...( the shame! ) yes i am trying to get the hud ladder to stay in the vertical plane with the VV. if it is attached solely to the beta, it works when you kick rudder, but not when you bank and pull alpha. hence the trig...to get the 'x' of 'y' in a bank. of the 2, alpha 'y' plays the bigger part (pulling) otherwise the value hovers around zero anyway. prior to seeing your post and since i do not know programing short cuts like using the stack i came up with; (A:Attitude indicator bank degrees,radians) COS (>G:Var1)(A:INCIDENCE ALPHA, degrees) (G:Var1) * (>G:Var1)....have to work in the beta, but it keeps the vv and ladder close. i was useing a routine i found in another hud...f-18 hud, the routine in awfully long and filled with operations i do not understand. i think he is useing a heading rate change to figure the offset...but the thing is flaky at altitude, extreme attitudes, and acts funny around 360 heading.i did not know how to divorce the heading referances, which i do not see as relivent. ( saddly, except when it goes nuts...it works really well ) but it refuses to center back up sometimes...so i am trying to hash out my own.(routine i found in hornet hud);(A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor (A:PLANE HEADING DEGREES TRUE, radians) rnor - abs 0.5 < if{ (A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor (A:PLANE HEADING DEGREES TRUE, radians) rnor - } els{ (A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor (A:PLANE HEADING DEGREES TRUE, radians) rnor < if{ (A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor 3.14159 + (A:PLANE HEADING DEGREES TRUE, radians) rnor - ) } els{ (A:PLANE HEADING DEGREES TRUE, radians) rnor 3.14159 + (A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor - /-/ ) } } }----------------------------sor b cos *is(A:INCIDENCE ALPHA, degrees) (A:Attitude indicator bank degrees,degrees) cos * (>some var here ) if you know how to do the rest ( figure in beta 'y' of 'y' in a bank)and combine with the alpha, i am all ears i will look at the hud course line....i am not familiar with it at present.

Share this post


Link to post
Share on other sites

>(routine i found in hornet hud);>(A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor>(A:PLANE HEADING DEGREES TRUE, radians) rnor - abs 0.5 < if{>(A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor>(A:PLANE HEADING DEGREES TRUE, radians) rnor - } els{>(A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor>(A:PLANE HEADING DEGREES TRUE, radians) rnor < if{ (A:VELOCITY>WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor 3.14159 +>(A:PLANE HEADING DEGREES TRUE, radians) rnor - ) } els{>(A:PLANE HEADING DEGREES TRUE, radians) rnor 3.14159 +>(A:VELOCITY WORLD X, m/s) (A:VELOCITY WORLD Z, m/s) atg2 rnor>- /-/ ) } } }>Yikes, I hate to say it, but that's some really ugly code. I can't blame you for looking for an alternative. For one thing, it's not using the registers at all. It keeps reading the same variables and performing expensive atg2 operations over and over again when they only need to be done once and stores in an s-register. It's also using logical operations that really don't look necessary.Here is one alternative:Suppose you have 5 elements that comprise the pitch ladder: two positive formatted text element, the horizon bar, and two negative formatted text elements: %90|------ ------|90n %50|------ ------|50n(A:Plane bank degrees,radians) s0 %45|------ ------|45n %05|------ ------|05nl0 Horizon barl0 %05|- - - - - -|05n %45|- - - - - -|45nl0 %50|- - - - - -|50n %90|- - - - - -|90nl0NOTE how each element above is rotated by plane bank /-/. Now shift all these elements 3 times thus:(A:Plane Pitch degrees, degrees) /-/(A:INCIDENCE ALPHA, degrees) (A:Plane bank degrees,radians) sin *(A:INCIDENCE BETA, degrees) (A:Plane bank degrees,radians) cos *1) First the ladder is being shifted to account for pitch. 2) Next it's being shifted to account for alpha, and compensated by the sin of the bank angle.3) Finally it's being shifted for beta, and again compensated by cos bank angle.The pitch ladder is now completely caged to the velocity vector as you would want.Only 2 trig operations, no IFs, and a #### of a lot easier to look at:) This could further be refined by integrating pitch into the other 2 shifts (2 shifts total), but there's no need really.Note since I stored bank angle in a register (l0) at the top of the ladder for the rotations, it can be referenced again with 'l0' instead of (A:Plane bank degrees,radians) for the shifts as well. I used the variable again for clarity in the example above.--Jon

Share this post


Link to post
Share on other sites

wow! i was useing bit maps....but only because i lacked the above tutorial.....i gotta gauge to build..er rebuild....thanks!

Share this post


Link to post
Share on other sites

JON,a few to many (snips) for me to go to a string ladder,(yet) but the shift part is SOLID! i can put the vv on in a box on the water line at any bank....haha had my sin and cos mixed up....thx.SIZE_X=8191SIZE_Y=4561i messed with the fs9 window when i started the panel....it gave me a screwy scale (25) but i finally got the waterline locked in through out the pitch range ( at least through the part where you can still see the horizon. ill mess with the string ladder.....a bit map to scale is HUGE...i had to brake into 3 pieces to get it to rotate. is there a hornet font? i looked for a free font maker ( with no luck) to try and create a good hud font.oh yea...no need for max & min...its locked in

Share this post


Link to post
Share on other sites

I never found a free font editor, so I bough Font Creator 5 by Hi-Logic. It was $65, which is very ceap for a font editor, and all I really needed. No, there is no Hornet Font in the public domain anyway. I created my own for special characters like "alpha", pitch ladder rungs, TD boxes, etc. I have probably 50 special symbols I use between the DDI's and HUD.The alphanumeric characters are all just based on Arial Narrow Bold.--Jon

Share this post


Link to post
Share on other sites

Howdy. ;-)I'm curious, beyond the "climb angle greater than eighty couple degrees" problem, (which I have fixed, and may re-release, along with other fixes and some neat enhancements), when, specifically, does the HUD "go crazy"?? I have not heard anyone else say that, in the dozen or so e-mails I've gotten, and certainly have not seen that on my computer. Or, are you referring to your version, where you pasted modifid portions of the code into your own HUD gauge??? Either way, I'm not aware of any other problems.... The weirdness around 360 should be fine in the original version, at least as far as the ladder and vector are concerned. (There was an issue with some of the heading tick marks around 360, but that was also easily resolved....) Or are you having a deiffernet issue? Also, would you mind explaining what the issue is that you experience "at altitude"? I've seen or heard nothing of this either. You do realize the HUD horizon will not match the Earth's horizon when high up in the sky, no? The HUD horizon rises, so that the vector, when on it, is demarcating level flight. (If you think about it, you can't be 40,000 feet up, flying towards the planet's actual horizon, and be in level flight....)Also, there's another thread below about using incidence beta for horizontal vector displacement..... Be careful with that. Beta does not (or should not) take wind into account. (Or are you saying you've done a kind of "heading minus track" calculation somewhere else, and then added beta onto that?) Anyway, you can do wind (heading - track) AND beta all at once by using those velocity body parameters that I used. I would think that would be much easier than dividing actual track and incidence beta into separate components, but honestly, whatever works for ya!Finally, there's a thread somewhere which I started which eventually goes on to give a more efficient way (macros) of doing some of those velocity body calculations. I did not know how to even use macros at the time of that HUD. (It was my first attempt at a gauge.) You could certainly clean your code up quite a bit by implementing those suggestions. That thread is probably only a couple of months old, IIRC.... Anyway, good luck with your HUD! Will you be posting it, is it for payware, or is it just for you?? Post some screens man!! I love to see people's HUDs. ;-)Good luck,Scott

Share this post


Link to post
Share on other sites

Hi Scott,I can't speak to the problems that people say they are having, because I haven't seen the HUD in question, but I would like to touch on beta. Yes, it's true (and a very important point) that wind is not taken into consideration with pure beta. In my case, I have to break wind into components for various other navigation functions (actually, I have to reassemble the components supplied by the X, Y, Z vars), so I add that to beta since it's cheaper than using atg2 again for a similar purpose.What I found wrong with the code snippet I was commenting on, was that it was too complex for a pitch ladder (if indeed that's what it was for). My apologies if I ruffled any feathers:) Regardless of the intended purpose, it could still be made much more efficient by the use of s-registers. Again, perhaps it's not in its original form, indeed not even being used for the purpose I thought.Also, just a quick comment on macros, and something that Tom has said before on another subject; macros won't necessarily make your code more efficient in terms of processing power. They'll make it much easier to manage and read, but everything within a macro is being iterated over as if its contents were expanded. You have to keep in mind that a macro is not like storing something in a variable or a register, it's going to be executed over and over again.But if you take (A:RELATIVE WIND VELOCITY BODY X, m/s) (A:RELATIVE WIND VELOCITY BODY Z, m/s) atg2 s0You can use l0 to reference that again and again throughout your subsequent code without the actual (expensive) calculation being carried out multiple times every pass.--Jon

Share this post


Link to post
Share on other sites

>>Also, just a quick comment on macros, and something that Tom>has said before on another subject; macros won't necessarily>make your code more efficient in terms of processing power.>They'll make it much easier to manage and read, but everything>within a macro is being iterated over as if its contents were>expanded. You have to keep in mind that a macro is not like>storing something in a variable or a register, it's going to>be executed over and over again.This is absolutely right.>>But if you take (A:RELATIVE WIND VELOCITY BODY X, m/s)>(A:RELATIVE WIND VELOCITY BODY Z, m/s) atg2 s0>>You can use l0 to reference that again and again throughout>your subsequent code without the actual (expensive)>calculation being carried out multiple times every pass.>>>--JonThis is right as well. The code that I posted on that thread was just an example, indeed not the most efficient.Using registers (s0..etc) like Jon does here is the best recommended.However, managing registers' values across the entire gauge needs to be done carefully. For example, as registers are a component of the stack, clearing the stack with a "c" operator also resets all registers to 0. Just a word of caution :-)Tom

Share this post


Link to post
Share on other sites

>>>>But if you take (A:RELATIVE WIND VELOCITY BODY X, m/s)>>(A:RELATIVE WIND VELOCITY BODY Z, m/s) atg2 s0>>>>You can use l0 to reference that again and again throughout>>your subsequent code without the actual (expensive)>>calculation being carried out multiple times every pass.>>--Jon>This is right as well. The code that I posted on that thread>was just an example, indeed not the most efficient.>Using registers (s0..etc) like Jon does here is the best>recommended. I often save an A:var to s0 before writing it to my L:var. If I need the value one or more times later. But, not down more than a few lines, otherwise I can't keep track of what is in the registers. Note "s0 (>:L:Var,number)" pops the stack, so I rarely need to use sp0, etc. But one does need to preserve the value which gets popped on the write if he needs it later and doesn't want to use the slower (L:Var,number) to recall the value. I never save variables in registers for long. If I need a variable in various places I write it to an L:var; but may also store it for use within the next couple of lines. I use s0 repeatedly, storing a new variable in reg 0 as soon as I no longer need the previous value.>However, managing registers' values across the entire gauge>needs to be done carefully. >For example, as registers are a component of the stack,>clearing the stack with a "c" operator also resets all>registers to 0. >Tom Never knew that; it didn't come up since I don't try to keep variables in registers for long. Often it's better to use 'd', perhaps with 'r'. That may be more difficult to work out, but avoids mixing up register contents. I think I've eliminated all register usage in my macros by using 'd' as needed. Simple example for anyone not familiar: "s0 (>L:Var1,number) l0 (L:Var2,number) * (>L:Var3,number)" vs "d (>L:Var1,number) (L:Var2,number) * (>L:Var3,number)" The "d" pushes stack 0 on the stack so the pop involved in writing to L:Var1 still leaves the stack with the original value. Which is then post multiplied with L:Var2 and written to L:Var3. If one no longer needs that value, the "d" approach avoids any register writes and also involves one less instruction. However, it is tricky to use "d" and "r" to avoid all 'sn', 'ln' operations; though especially desirable in macros. Ron

Share this post


Link to post
Share on other sites

Scott, The problem with the code was no doubt because I tried to use it out of context. I actually liked your HUD very much

Share this post


Link to post
Share on other sites

Hi again. I see now what you're saying. Thank you. And yes, there is definitely a lot to digest in all the various threads you mention! As to the HUD ladder horizon shifting with altitude... just to be clear, that is not something I put in the code. That is somewhere in the FS9 code itself. Your gripe is with Microsoft, then. Heheh. ;-) All my HUD does, really, is put the longitudinal axis/waterline where it should be (if the instructions are followed), then move the velocity vector and ladder around accordingly. If you're flying straight and level at, say, 40K feet at an AoA of 5, the accuracy of the HUD ladder and vector can be easily cross-checked. When I do this little cross-check:1) The waterline is not moving, obviously, (and remains where the V would be if you turned on the axis indicator in the Fllight- Options menu);2) The vector location appears to be accurate. (It's on the HUD horizon, 5 degrees below the waterline); and3) I did not include any code to shift the ladder up with increased altitude, so... I am left to conclude that the magnitude of this horizon shifting with increased altitude is done by FS9 itself. Actually, you can fly any other FS aircraft at high altitude, turn on FS9's default axis indicator, and see the same effect. (Of course you have to take into account AoA also....) Whether FS9 does this absolutely correctly or not I'm not qualified to say.... A quick look at some HUD photos on airliners.net makes me think that, yes, the effect is exaggerated in FS9.Oh, BTW, you hit on something else. No, my HUD won't autoscale. I don't believe autoscaling could be done with the variables we're currently given by MS, but I agree, it would be great if we were somehow given that capability. (To do it we'd need window size variables, gauge size variables, etc.) So, as you've found(!!), if you adjust the zoom or the window size, you're changing the number of degrees of outside world displayed on your monitor, and thus the ladder and vector would no longer be accurate. You could make the HUD work for any zoom setting or window size you want, but you'd have to calculate a new "pixels per degree" and adjust the pixel values in the XML file (and the ladder spacing) accordingly.Anyway, thanks for the comments, and thanks everyone else for the good discussion and insight. I'm going through a phase where I'm not flight-simming or working on gauges much. (I have MANY hobbies... I'm a jazz drummer, I'm into art, I play Call of Duty UO online WAY too much, etc., etc.... In other words, unlike most in here, I flightsim for a few months, then won't touch it for a few months, then pick it up again, and so on....) What I'm getting at is... if I do ever release a new version, God only knows when that could be! But I will most likely get to it at some point this Spring. Thanks again, and good luck with your SAAAB HUD!Scott

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this