A note on the internal structure of X-Plane 10:
As X-Plane grows in scope to be a world simulator, not just a flight simulator, with many process to fly airplanes by air traffic control, drive cars along the roads and highways, and build forests and cities according to interesting little algorithms, all at the same time, it becomes clear that the organization of the code is becoming absolutely critical to handle all of these many processes at once without introducing extreme complications and bugs from countless interdependencies. Weather controls absolutely everything that is going on from the deer and birds to the hot air balloons to the rain and snow and ice to the type of instructions you get from air traffic control. Forests are actually planted in front of you on secondary CPUs as you fly, and cloud puffs, radar images, and even the flight models of other airplanes are running on secondary CPUs at the same time. There are countless processes all running at once to drive this virtual world, and if each process is not well-designed and insulated from the others, then crashes, bugs, and chaos will ensue.
So, how do we deal with this? The answer is object oriented programming. Here is how it works: each entity in X-Plane (say, for example, the deer that run across the runways from time to time) is it’s own little object of code. This object is its own little bit of instructions and memory, and this object is not allowed (and in fact does not know how) to access the functions or memory of any of the other objects in the X-Plane world. Each object contains its own logic and instructions, and I can safely forget how each object works when I am done coding it, because it is an insulated unit that cannot effect anything else. For example, the deer object will look at where you are so they can run and bound about at whatever airport you are near, using their own little primitive brains to decide where to run based on the size of the airport, weather, time of day, and your location, but the deer object does not know how to change the location of your airplane… Because your airplane is, of course, a totally different object. Since the brains, memory, commands and accessors for each object live within that object, they are not easily messed up by any other object. (A command for an object might be: “Deer object! Run out onto the runway! I command you!”, and an accessory for an object might be “Deer? Where are you? I need to know your location to plot you!”)
You will notice that neither the command nor accessor is actually allowed to get inside the logic or memory of the deer object… That would be dangerous because it could mess the deer object up. Instead, there is a firewall around every single object in X-Plane that keeps one object from messing up another, only allowing commands (which the object can follow if it deems fit) and accessors (which the object can provide safely). Other objects cannot go through this firewall to mess with the internal logic of each object. This object-oriented programming is what makes something as complex as X-Plane 10 possible. In the movie The Matrix, it was clear that the virtual world was complete, and made of countless computer programs all running at once… And this is where we are going with X-Plane 10: a virtual world, not just flight sim, where countless things are all happening at the same time.
Now, one obvious fallout of this is that you will want your computer to have many processors. Lots of them. With my 8-CPU, 16-core Macintosh, I saw over 100 frames per second (with no scenery) with 20 planes all flying simultaneously yesterday. Try setting the number of planes to 20 in X-Plane 9 and see how fast it runs. The difference is that X-Plane 10 has each airplane as it’s own object, and each object running on a different CPU, all at the same time. Multiply this by the ever-growing forest (the trees have to be planted in front of you as you fly… You do not have the RAM to memorize them all) animals, cars, air traffic controller, boats, ever-changing weather, and you start to see why it will take a lot of CPUs to run this complex world. But, an interesting thing is that with no scenery, I am seeing X-Plane 10 run much faster, and use less RAM, than X-Plane 9… This is because the objects are all packed so efficiently with minimum RAM use, and run many at the same time to give more speed. (Note: this RAM check was done before I finished installing the new weather system. The new weather system, when complete, may cause the total RAM use to be slightly greater in the won-scenery-case… We will see when the weather system is done.) Interestingly, the system that determines what the weather is in X-Plane 10 uses almost zero memory! This is because the weather is stored as a fiendishly-clever little algorithm that tells X-Plane what the weather is at any given location and then promptly forgets what it just said. This gives all the variation in the weather we could want, but without using any RAM at all! It does use memory, however, to memorize where to draw the clouds. The drawing part must be memorized for speed, because the video card can only do its work fast if you hand it the whole world of clouds to draw at one time, not one little cloud-puff at a time. So, for speed, we must use memory to store the location of every cloud-puff in the sky, but not the weather that caused those cloud-puffs to exist: that part was done by the weather-making object and its own internal algorithm.
Another nice thing about this object-oriented system is that it makes it much easier to track down and solve bugs without causing new bugs to appear by solving old ones. Because each object has its own logic and memory, any bug should, in theory, be traceable back to the object that is malfunctioning, where it can be fixed without affecting any other objects.
So, while X-Plane has been gradually broken down into objects for some years now, with version 10 we are really making it all object-oriented internally, and combined with the multi-threading, the results are really quite impressive.
austin
