How long have you been working on project ''GSX''

[lionking]

Hi Umberto,


My first question is pretty simple, how long have you been really working/studying/considering on the GSX software? And what time did you and your team start thinking about, whether there could be any possibilities to create such a complex program.

And 3rd: What do people start, or rather, what did you start developing GSX from scratch with?

It's simply fascinating me endlessly, probably because I've never done anything with programming or stuff like that.


Thanks in advance...  

[virtuali]

We started laying out the foundation in 2009, then had a stop for almost a year because of other projects the GSX team was involved with (including some games on the iPad...), so it's basically a 2 years work.

However, the GSX foundation comes way earlier than that, and it's our FSX script engine which is based on the Python language (a special version of it, optimized for games), which runs entirely outside FSX, under the Couatl.exe program, which is a custom Python interpreter.

This allows to write whole programs using modern language constructs like classes, lists, and it also wraps the Simconnect API AND it can access FSX native API function that Simconnect doesn't expose too, this made with the help of the Addon Manager. The Python script are the "glue" that connects all of this into a seamless environment.

The first product that used this was XPOI, which is also written entirely in Python, then we perfected it to add additional features we needed to create interactivity in sceneries (like docking systems, intelligent taxiway lights, weather-based objects, objects that appears at different dates, etc.), and improved it even more, to add all that GSX needs to access AFCAD, guide vehicle, find optimized paths, handle custom animations, and a lot more.

[lionking]

Not reasonless are developers working very long on certain projects, indeed!

When you said that everything is doing outside the FSX, did that mean that GSX or other FSDT addons doesn't really work inside FSX, so just for people's eye they are in there? Would the FSX engine not even allow those many functions, too? Or am I now comparing the incomparable? 

[virtuali]

The Python logic works entirely outside FSX, in the Couatl.exe, which runs alongside FSX.

This means all our Python scripts will run on a different core than FSX, and Windows itself will handle the scheduling. On a modern multi-core system, there's a *lot* of available cpu power which FSX doesn't use, but in-process modules ( FSX addons using .DLL ) will run on the same core as FSX, potentially impacting performances or possibly slowing it down or creating small pauses, when they do complex calculations. With our approach instead, even when GSX should start a complex calculation, it won't be able to slow down FSX, because it runs on a different thread which is allocated on one of the spare core which FSX doesn't use.

On top of that, on a 64 bit OS, each process can use up to 4GB of RAM so, FSX and *all* its .DLL modules (including 3rd party modules AND gauges) will take from this 4GB pool. Instead, since Couatl.exe is a different process, it has its *own* 4GB memory space, separated from the FSX one, which means we can allocate lots of ram without worrying about causing Out of memory errors, which plague FSX when used with complex addons that have most of their code in .DLL and .GAU files.

We also have a .DLL module, the Addon Manager, but its scope is very limited right now, since it's only used to give Couatl access to the few things that can't be read using Simconnect, so they are only accessible by an in-process .DLL, but it's a very lightweight work, no complex code is running inside the Addon Manager anymore, most of the work is done by Python scripts running under Couatl.exe.

Is not the simplest of the architectures, but it's what grants us the most performances, and can grow with many new features, without affecting FSX memory consumption or possibly slowing it down if scripts becomes too complex, so it has lot of room for expansion, considering we'll get more and more cores in the future, memory is always cheaper, and most users finally upgraded to a 64 bit OS, which is the best option for FSX right now.

[lionking]

Would an entierly new flight simulator (I don't count the Microsoft Flight as one) be more performace friendly, comparing to the FSX, though there'll be a slightly better graphic and more animations too. I read that the FSX wasn't developed in a neat quality and so they risked having a lot of performace issues with their new game. Despite that FSX was released in 2006 and hence, most customers who are really interested in aviation and are even flight sim enthusiastic have yet updated their hardware already. Nonetheless, in what relation was FSX's huge perfomance hunger relevant to you and the addons you have been creating? And specially the thingy with the passengers is wondering me even more. So far, you are likely going to create this feature, one problem as you mentioned, that's now existing, is the performance that might occur some crashing computers, but when couatl and all the rest are running on another thread than FSX and you even can get 4GB ram if available, than why is it still so difficult to find/make a frames friendly solution? My question was not meant in the way that you're in a bad spot, but only because I'm quite wondering.

[virtuali]

is the performance that might occur some crashing computers, but when couatl and all the rest are running on another thread than FSX and you even can get 4GB ram if available, than why is it still so difficult to find/make a frames friendly solution? My question was not meant in the way that you're in a bad spot, but only because I'm quite wondering.

We don't affect FSX performance when we run our code, which does calculations, path finding, read/write files, etc.

But the moment we create a graphic object like an animated vehicle or human character, it WILL affect performances just the same as if it was created by a module running inside FSX, and will force FSX to allocate the memory required for it from its own memory.

[lionking]

But the moment we create a graphic object like an animated vehicle or human character, it WILL affect performances just the same as if it was created by a module running inside FSX, and will force FSX to allocate the memory required for it from its own memory.

So am I right by assuming that you kind of send the objects and animations to the FSX by sending its the GSX's data? And so, at the moment when it's creating all those objects, the FSX is actually working only and not couatl as it has already sent its data? 

[virtuali]

So am I right by assuming that you kind of send the objects and animations to the FSX by sending its the GSX's data? And so, at the moment when it's creating all those objects, the FSX is actually working only and not couatl as it has already sent its data? 

Not exactly, GSX is always working in the background even after the object has been created, because it's coordinating all the animations and the synchronization between different objects and their actions. It also handle their sounds, since all GSX sounds are made entirely independently from the FSX sound engine, since GSX includes its own surround sound engine, based on OpenAL.

This processing doesn't impact FSX performances at all. Making GSX "smarter" and doing more sophisticated calculations is entirely possible, without risk affecting FSX fps.

The actual display of objects, which is made using the FSX graphic engine, can affect performances, but not any different has having a couple of AI airplanes more on screen.

[lionking]

But GSX puts vehicles and animations into FSX that aren't standard at all. Why is it then still not possible to create software that animates a second or even third jetway docking system? How does AES handle this? Could you do the same with your engine? The last question is not a request question to do that, but only a possibility question.

[virtuali]

But GSX puts vehicles and animations into FSX that aren't standard at all. Why is it then still not possible to create software that animates a second or even third jetway docking system?

Who said it's "not possible" ? We never said that, we said we don't want to enter in the business of individually support each 3rd party scenery with missing jetways, because that will mean having to *charge* separately for every airport. It's a business model we'll happily leave to AES.

How does AES handle this?

In its own way, which it's different than what we might do on FSX, since AES have to be compatible with FS9 too.

Could you do the same with your engine? The last question is not a request question to do that, but only a possibility question.

Yes, of course we can do it, and we'll likely to do it, but probably for our own sceneries only.[/quote]

[lionking]

Who said it's "not possible" ? We never said that, we said we don't want to enter in the business of individually support each 3rd party scenery with missing jetways, because that will mean having to *charge* separately for every airport. It's a business model we'll happily leave to AES.

I even thought that when I write that, you would might give this kind of answer, but I figured, maybe you won't say that!

In its own way, which it's different than what we might do on FSX, since AES have to be compatible with FS9 too.

On its own way..., yes, likely!