Traffic Global for X-Plane Dev Diary – April

Originally published on https://www.justflight.com/articles/developers-diary-traffic-global-for-xplane-11

Welcome back! Last month I made a promise – no more talk about traffic schedules – and you’ll be pleased to hear I plan to keep that promise, not least because it makes my head spin. This month I’ll dig a little deeper behind the scenes; we’ve already talked about the models, and the schedules, so next we need to tie the two together and track which planes are where, and a lot more besides. Oh, and (drama pause): Framerates.

Remember, X-Plane doesn’t offer any of the basic services you might hope for when it comes to adding AI aircraft. If you want a model to appear in the world, you need to tell X-Plane where to put it, every single frame. On top of that comes animation, sound, awareness of other traffic and the player, and route-finding, so this is a fairly significant amount of work to do, and it needs to be done for every plane, for every frame the simulator displays.

The traffic database I’m working with right now, which is smaller than it will be on release because bits of last month’s dev diary still make me start twitching, has about 15,000 active aircraft flying about 70,000 flights a day. If we were to go with a brute-force approach it would mean that every detail for each of those 15,000 planes would need to be calculated somewhere north of 30 times per second. “Every detail” means just that – how far have each engine’s turbine blades rotated? Exact positions for each set of landing gear, control surfaces, lights, thrust reversers, and so. There’s an obvious problem here – “Frames per second” just turned into “Seconds per frame”. Mercy me, what to do? Run and hide isn’t an option.

Optimising code basically falls into two camps. “Do Less Work”, and “Do Work Faster”. The approach for the first of these is pretty obvious, we need to cut down the number of aircraft that we’re looking at every frame. Happily, that’s quite straightforward. All we need to do is work out roughly where a plane is and, if it’s so far away that there’s just no way it’s relevant, don’t bother doing anything more detailed. That still takes time, though, so it’s not enough.

OK, so what else can we do? How about not calculating all the details if a plane’s not on screen? That’s great, but you still need to work out where it is (and a bit more) to know whether it’s on screen or not, so still more is needed, and this is where it gets a bit fiddly. There are lots of places where we can decide that some bit of information or other really doesn’t matter, but deciding whether it doesn’t matter or not sometimes takes a bit of time to work out itself, so it comes down to lots of testing, balancing and re-testing (as well as a lot of experience and intuition) to know which bits to put effort into. Some are easy though; for example, if we’re in mid-cruise then we probably don’t need to know how far each landing gear wheel has rotated because it’s a) not rolling, and b) retracted – and, yes, X-Plane needs this level of detail provided!

That still leaves a metric bucketload of work to do every frame though, so what else can we do to cut this down? First let me say that there’s a lot more being done to reduce the workload but I’m not giving away all the secrets here! Skipping swiftly past that, we come to the second approach – “Do Work Faster”.

A typical workspace – two 4K monitors!

At least that one’s easy. Simply buy a faster CPU. Job done. No? Oh, OK. How about this then: use the CPU you already have, more efficiently.

Once upon a time, home computers had a simple CPU which could do one thing at a time. The operating system made it look like it was doing more, but really it was just one thing at a time. If you wanted more than that you had to buy a special motherboard that could take two equally special CPUs, buy a special copy of Windows (yes, yes, or any free copy of Linux), and then you could do two things at a time. I actually had one of these back in 2004 or so and it cost the same as a decent second-hand car. Nowadays things are better though, and everybody has multi-core and hyperthreading CPUs which can genuinely do loads of different things at the same time.

(Mini-glossary: A CPU core is basically a unit that runs a thread. Two cores, two threads at the same time, twice as fast. Four cores, four… you get the picture. A thread is the techy term for a sequence of processor instructions that need to be run one after another. It’s different to a “program” because a program can be made up of many different threads. Hyperthreading is a cool trick where a single core can genuinely do more than one thing at a time with reduced efficiency, very roughly equivalent to 1.6 cores. Techy stuff over, you can pull your fingers out your ears now.)

The problem here is that X-Plane, and Prepar3D, and many other CPU-heavy programs are still not really using the CPU to it’s limits. They’re still mostly “single-threaded” – they do one thing at a time even though the CPU can do way more than that. That’s not because the programmers are sloppy or lazy, it’s usually partly because important bits of the code were written before multi-core CPUs were widely available and partly because multi-threaded code is surprisingly difficult to get right, especially if you’re trying to convert older single-threaded code. The problem is that if one core is reading some data at the same time as another is writing it, all sorts of random problems, or even crashes, can start happening completely unpredictably. Thing is, if you make one core stop work to wait for another one to finish, you’re losing the benefit of doing more than one thing at a time. Simply making one stop and wait takes a bit of time to do, even if it doesn’t actually need to wait. Introduce three or four threads all trying to access the same data and organising them can get really hairy.

Just to make things that little bit harder, X-Plane insists that if you’re interacting with it from a plugin, it absolutely must be from the same thread that is responsible for all of X-Plane’s own work so there are very tight limits on what can be done using a different CPU core. Anything that’s done on this special thread will inevitably lower the framerate. Adding and removing aircraft, positioning them, reading the current weather conditions, getting the ground height at a particular point to make sure that planes touch the ground and don’t hover above it or sink through it, interacting with the UI, even certain types of essential maths must always be done in a way that can’t help but make X-Plane a tiny bit slower.

The strategy, then, is to never make X-Plane wait for anything, do as much as possible from other threads – and there’s a surprising amount that can be done in the background, given all the restrictions – and obviously keep the amount of work to a minimum throughout. It doesn’t matter what else is done if the framerate drops too much, because people just won’t hang around long enough to see any of the clever stuff. There’s no way I’m daft enough to promise no drop at all, but I will go so far as to say that even at really busy airports I’m not finding the drop noticeable – simply being at a detailed airport has a far, far bigger impact. Whether or not other people agree remains to be seen!

A busy airport. All these planes are AI.

One other major change happened this month: Traffic Global for X-Plane was announced. World plus dog now knows that it’s coming and is expressing some fairly definite opinions on what it should be, and I’m working on one of the other really important areas that simply cannot go wrong – the details of both airborne and ground handling. No pressure, chaps, just keep soldiering on.

About the Author: jimkeir