C/C++ or Lua (sasl, gizmo)

[ksgy]

Hi,

 

I'm very puzzled about choosing between C/C++ and Lua as main plugin language for my L-410. Looks like Lua language is much more efficient in development time, but in the other hand C/C++ is much faster.

 

Since I'm planning to implement almost all the system functionality to L-410, a question came up: is it worth to use Lua? As IXEG team uses SASL for systems, I prefer to use that too. But don't know if it can handle lot of calculations effective, and also I prefer not to use script language as good programming sense says C/C++ is the right way of doing this

 

I'm writing a complete engine model (initially in JavaScript for easy debugging) to cover performance graphs in manual. E.g. here is an example for ITT:

http://x-plane.hu/temp/L410/model/ (change black (thr) and/or green (spd)). Source: http://x-plane.hu/temp/L410/model/engine.js

 

There are some interpolation calculations in code and this is just ITT (fuel consumption, N1, N2, oil temp, hydraulics, etc will to come). Can Lua handle this kind of math?

 

So convince me!

 

 

Thanks for answers.

[Cameron]

As IXEG team uses SASL for systems, I prefer to use that too. But don't know if it can handle lot of calculations effective, and also I prefer not to use script language as good programming sense says C/C++ is the right way of doing this

 

IXEG uses Gizmo, not SASL.

 

Gizmo is very powerful and can do anything (so for that I have seen) that you can do in C, and very efficiently. In all honesty, the 737 is the most advanced aircraft for X-Plane in production to date, and given it's LUA driven that in itself is all you need as a testament. Because of the JIT (Just In Time) compiler used in Gizmo the performance "hit" is practically negligible in comparison to C...you honestly wouldn't notice it in my experience. Any calculation or desire you have can be done with Gizmo so long as it's within the realm of the X-Plane SDK and you know your syntax. And, as you've mentioned, it's very fast to develop in.

 

SASL does well from what I have witnessed, but has limitations against it that Gizmo does not. The major reason for this is due to the way the plug-ins were architected. At this time SASL works well in some areas, but lacks in many others. It works for those who use it within its limitations, and may do the same for you. 

 

I don't want to make this a Gizmo vs SASL war, so I'll leave it at that.

 

Yes, LUA can handle your math.

[tkyler]

I think perhaps we have over 30,000 lines of Lua code on the IXEG 737 and while there is a performance hit, it is surprisingly low, especially on a modern machine. As Cameron says, with LuaJIT, the code is compiled code, not interpreted "on the fly" so it runs really quick....and TBH, we are talking functions that run in billionths of a second and compared to what XP is running, aircraft systems code (if decently written) is usually negligible. Ben Supnik concurred that unless you did something really irresponsible, it's unlikely you'd see a performance penalty.

Here's my thoughts on each, clearly I'm biased towards Gizmo, but will try to be objective:

C++:
Doesn't require dependency on anybody else. Runs quick, full support of SDK. 3 platform support a PITA, having to reload aircraft to reload the plugin is a PITA. That's what put me off on C++. I can do it, but my goal isn't to have fun programming or challenge my programming skils, my goal is to produce a simulation. So while I've done two C++ plugins, I prefer the Lua scripting.

Gizmo:
Depends on Ben Russell. He dies or decides to pull it, your stuck. Ben's been around over a decade though so he has my vote. Gizmo has some licensing restrictions that favor X-Pilot and X-Aviation....don't expect to use Gizmo and upload work to the org to share or sell.. Almost full support of SDK functions though, including openGL and openAL functionality. Also has support for particles and physics and internet communication (correct me if wrong Ben). Gizmo mimics the x-plane SDK API very well so it's a bit easier for me to comprehend having worked in C with the xplane SDK. Performance perhaps a tiny bit behind C++, but for me that is not enough of a motivator to ditch the crazy development speed I get with Gizmo. No support for easy 2D popups, you have to make your own, but the tools are there.

SASL: Depends on somebody...I'm not sure. I think Philipp was the last to "save" it. SASLs open source with no real restrictions. I do not think the original authors works on it anymore but I can't confirm this, anyone? SASL has a specialized API originally designed for 2D "gauge programming" and is therefore very suitable for 2D pop-ups and you'll see lots of SASL products utilize this feature, but has support for sounds also. I don't think it has the graphics horsepower of Gizmo's GL implementation though. We use Gizmo GL frame buffer objects on the 737 to render to offscreen textures and other things necessary for EFIS drawing operations. With the ability to read and write datarefs, then systems coding is pretty much the same for SASL as it is for Gizmo.

As far as C++ being a "real language" compared to scripted languages, that argument does not work for me. I think such an argument contains a bit of "programmer pride", a sort of status symbol to say, "hey, I'm smarter than you...you can only program in a scripting language"....but that is ridiculous, these are all just tools and you should use the best tool for you to get your goals met. I've used both and my development requirements are speed and stability..speed of development, speed of code running and stability of the running code and the stability of gizmo development. In my opinion, you can produce faster results with Gizmo than C. Plain text files, 3 platforms supported...no loading and unloading of aircraft during development lets you focus on getting results, not fighting platforms and compilers. As to why I myself would pick gizmo over sasl....the first reason is I'm familiar with the API structure and the 2nd is the more robust openGL implementation. If neither of these matter to you, then I think either would fill your needs.

Lua can definitely handle your math whether in SASL or GIZMO and with its primary data type being a table (same as object in javascript...also called hash table.....the whole key/value pair thing)...you would probably be very comfortable with Lua right away.

Tom K

Edited January 29, 2013 by tkyler

[Cameron]

Gizmo has some licensing restrictions that favor X-Pilot and X-Aviation....don't expect to use Gizmo and upload work to the org to share or sell...

 

While Gizmo 12 has been in development many ideas have been entertained and sharing will definitely reach the masses in a much better way than was previously offered or shown. We won't be entirely shunning the org, and projects can be shared there. I'm sure Ben will have more on this as time rolls on with announcements and finalization of the Gizmo 12 plug-in. It's leaps and bounds better than we've ever had before!

[tkyler]

Cool.   that sounds good!  Sorry for the mis-info.

 

TK

[Cameron]

Cool.   that sounds good!  Sorry for the mis-info.

 

TK

 

Sorry, Tom, meant it more as a clarification. It's easy to get lost in all that has been going on with the updates behind the scenes!

 

Hope all the info Tom has provided you is helpful in making your decision, ksgy!

[ksgy]

Thanks for the answers, and sorry for the mix up about IXEG

 

I think I'll wait for Gizmo 12 and check it's features. Meanwhile I'll look into SASL and current Gizmo and will make a final decision later.

I found this: https://sites.google.com/a/x-plugins.com/www/gizmo/downloads - are these the latest gizmo plugins? Seems like linux builds doesn't have LuaJIT enabled. Or is there somewhere else available a more recent version?

 

In general, I don't like 2D popups in planes, so drawing on panel or opengl is not required for me. More like creating and using own datarefs based on own calculations.

 

Gizmo seems more reasonable decision cause of future support, SASL's destiny and continued development is not guaranteed as I see now.

 

Thanks again for clarifications for both of you

[rvt]

I am properly a bit late in the game, Lua vs c++ (or plain c)

 

But I see it like this.

 

1) You properly gain more speed by optimising your Lua code then changing your language from Lua to C or C++.

2) If you are wondering about this question in the first place, you should properly stay with Lua.