Sign in to follow this  
Guest EdrickV

is FSX XML only? RPN is just too painful...

Recommended Posts

I realize RPN was chosen as pulling the elements of programming statements and expressions in a queue is easier than jumping around, but the RPN is just too painful. Infix is human-friendly and the standard for most languages. I would hope that with FSX breaking tasks across fibres in a more efficient manner that the performance gains of postfix could be realized in other places: like the use of stronger machines, multi-cores or and what sounds like a more efficient multi-threading approach.XML gauge programming is a blessing on one hand, but RPN is just too much mental contorting... when will a straightforward system, such as occurs with modern interpreted/compiled languages be available to us? honestly, I'd rather be able to compile a gauge and use a contemporary infix-style language like C, but the C gauge SDK is a serious nightmare. XML was a step in the right direction, but the RPN absorbs any gains with its inane difficulty. This is especially true with complex compound expressions and statements.I just wish that gauge and systems programming could have grown up along with other features in Flight Simulator. Honestly, RPN and XML gauges feel like a kludge holding us over until a comprehensive OO scripting approach emerges.oy vey...

Share this post


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

>honestly, I'd rather be able to compile a gauge and use a>contemporary infix-style language like C, but the C gauge SDK>is a serious nightmare. XML was a step in the right>direction, but the RPN absorbs any gains with its inane>difficulty. This is especially true with complex compound>expressions and statements.Granted, the SDK 'sucks hind teat,' but it really isn't that difficult!There's plethora folks using C, C++ and GDI+ here and in other forums to provide guidance.I highly recommend Dai Griffith's tutorial: sd2gau18.zip as a terrific starting point.You can download the latest MSVC++ .NET 2005 Express Edition for free from Microsoft's website. There's a tutorial series anchored in my "Panels and Gauges" forum at http://flightsim.com illustrating how to set up the IDE for gauge production.

Share this post


Link to post
Share on other sites

I find Algebraic notation to be more difficult than RPN. Been using RPN in HP calculators since 1975.W. Sieffert

Share this post


Link to post
Share on other sites

Yeah, I've been using RPN as long on HP calculators... I remember the first thing I ever programmed was a Monroe 1880 programmable calculator. I still remember Halt was code 301 which I had to punch manually into a punch card with a paper clip on a special holder.If you don't understand the MS header, the key is to remember your basics and that this is MS's attempt to simplify the coding with macros. If you have never used macros before, then it can be a bit confusing, but if you have strong basics it will not take long to figure out.To really get it though, it helps to have some background game programming, particularly understanding the concept of a game loop, and basics about rendering. Beyond that, you'll also want to learn about .dll's over time.

Share this post


Link to post
Share on other sites

FS2k and FS2k2 style gauges are usable in FSX, including the default gauges from FS2k2. (AKA the multiple gauges in one .gau file system.) FS98 style gauges (one gauge per .gau file) aren't supported. I imagine there are more differences between the two types of C/C++ gauges, but I don't know what they are."Let me help you out. You're cleared to taxi any way you can to any runway you see."

Share this post


Link to post
Share on other sites

thanks for the replies...Algebraic notation is defacto standard now and many of us have come up using that notation to program. HP-style RPN is not common now.Norms in development have moved away from MACROS and other such customizations on-top-of C. I was just hoping for a comprehensive library accessible in an object-oriented style.I make a living teaching people contemporary programming techniques and languages. It is unnerving to have to step back 20-30 years to do development for FS. I am capable of it, but the transition hurts.When I first played with XML gauge programming, I was very enthused as I thought it was such a step in the right direction. However, the deeper I got into RPN, the more frustrated I got. I spend my workaday life in extremely straight-forward infix languages and I guess I'm just not crafty enough to devote the patience to let the RPN sink in.In any case, RPN and the macro-laden C gauge SDK are both archaic.In any case, does anyone know the answer to my original question regarding the approach for gauge making in FSX?Thanks

Share this post


Link to post
Share on other sites

>In any case, RPN and the macro-laden C gauge SDK are both>archaic.>>In any case, does anyone know the answer to my original>question regarding the approach for gauge making in FSX?Since this was the only question asked, I have to assume this is what you're referring to:"XML gauge programming is a blessing on one hand, but RPN is just too much mental contorting... when will a straightforward system, such as occurs with modern interpreted/compiled languages be available to us?"I should think the question has been answered, albeit obliquely... ;)The direct, succinct, to-the-point answer then is an unequivocal when pigs fly... :-lol Of course, no one is forced to use the SDK's macros. One always has the option of 'unwrapping' the macro code to expose the lower level, brute-force code... ;)

Share this post


Link to post
Share on other sites

I agree. C++ is an object oriented language and what are gauges if they are not objects? Unless it's changed in FSX the currect approach is completely outdated.

Share this post


Link to post
Share on other sites

>I agree. C++ is an object oriented language and what are>gauges if they are not objects? Unless it's changed in FSX the>currect approach is completely outdated.Any technique you choose to do in FS9 or FSX may be done, providing that it is possible at all within the constrants a DLL...

Share this post


Link to post
Share on other sites

>You can download the latest MSVC++ .NET 2005 Express Edition>for free from Microsoft's website. There's a tutorial series>anchored in my "Panels and Gauges" forum at>http://flightsim.com illustrating how to set up the IDE for>gauge production.Interestingly enough, I cannot ever get that IDE to work again with GDI+. Started off with a new project based on the usual SDK gauge, then tried to add the GDI+ headers/lib, which forced compiling to stop due to those four errors I remember I have had *some*time about a zillion years in the past, but now can't seem to get 'em fixed, for whatever reason. I am talking about "errors" within gdiplus.h, starting at line 25:(25) C2061 syntax error: identifier 'Gdiplus'(25) C2059 syntax error: ';'(26) C2449 found '{' at file scope (missing function header?)(69) C2059 syntax error: ';'These are obviously no errors at all since GDI+ used to work all the time before. Now I suspect some dumb mistake I am doing while trying to set everything up again here. If anyone has a neat hint, do not hesitate to scream away. :)Thanks in advance.Etienne

Share this post


Link to post
Share on other sites

#define ULONG_PTR DWORD#define UNICODE#include #pragma comment (lib, "gdiplus.lib")using namespace Gdiplus;

Share this post


Link to post
Share on other sites

I think I have cured the problem, although I still cannot 100% understand how that could happen. It works at least. :)

Share this post


Link to post
Share on other sites

>#define ULONG_PTR DWORD>#define UNICODE>#include >#pragma comment (lib, "gdiplus.lib")>using namespace Gdiplus;The line #pragma comment (lib, "gdiplus.lib") shouldn't be there.gdiplus.lib should be listed in the Linker section of the Project file's Properties...Here is the complete header for one of my gauge projects, with the GDI+ specific lines highlighted in red:#include "..incfs9gauges.h"#include "ESXLS_Misc.h"#include #include #include #include #include #include "BCD.h"#include #include #define ULONG_PTR DWORD#define UNICODEusing namespace Gdiplus;GdiplusStartupInput gdiplusStartupInput;ULONG_PTR gdiplusToken;

Share this post


Link to post
Share on other sites

Thanks Bill, actually there is no difference if you link with IDE or pragma...The include section looks similar to yours. I got it working earlier today.Thanks for your help though, still greatly appreciated. :)Etienne

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