Keyboard Mapping - seemed like a good idea at the time

X-Plane 860 introduces a fundamental change in the way the keyboard is handled in X-Plane.

Before X-Plane 860, keyboard keys are matched to their commands by looking at the character that is prodcued by typing.

For example, spot view is produced by the '@' symbol. On a US keyboard that means shift-2. On an Italian keyboard, the @ symbol is shift + the ò key (ò on its own key, cool!).

But in X-Plane 860, the matching is done on the key itself, not the symbol you get when typing. In other words, the 2 key is the 2 key no matter what. So in X-plane 860, spot view is mapped to shift-2 and shift-2 will induce spot mode whether this gives you @ or " when typing (on Italian keyboards, shift-2 gives the double-qoute).

One advantage of this method is that the keys stay in roughly the same place...the point of those strange punctuation keys for autopilot modes is that on a US keyboard they're all top-of-the-keyboard functions. Now that the keyboard bindings are based on the number keys plus the shift key, this will be true on international keyboards too.

One disadvantage of the new system is that if there is no "primary" key for a symbol, international keyboards can't use it. For example, ; is a key on a US keyboard, but is made by shifiting the , key on an Italian keyboard. So right now in beta 2 Italians can't invoke free-view (ctrl-;) at all...if they type ctrl-shift-, they get, well, ctrl-shift-,. (Of coures, mapping free view to ctrl-shift-, in the keys file does work.)

For now please just keep in mind that 860 is a beta and is still a work in progress. In the long term once we get the quirks worked out, the new keyboard system offers a lot more mapping combinations, because everything can be mapped with any combination of modifier keys. No more running out of keyboard combinations!

Also for hackers, try X-Plane --cmnds=all to see a list of all possible command bindings in the sim.

Using GLSL does not mean changing the system requirements!

X-Plane 860 uses GLSL pixel shaders. But this doesn't mean you need any new hardware. It does mean you might need to update your drivers. Let's break this down a little bit.

X-Plane never talks directly to your video card. It always talks to the video driver, a piece of software that acts as a translator between X-Plane and your video card. (That's a gross simplification - video drivers do a lot of amazing things these days.)

Your video card has certain capabilities - different cards can do different tricks. The video driver tells X-Plane what tricks the video card can do.

So there are really four possibilities for any given trick:

1. Your video card cannot do that trick. The video driver will tell X-Plane "I can't do it."
2. Your video card can do that trick. The video driver will tell X-plane "I can do it".
   
3. Your video card can do the trick, but the driver is old and will tell X-Plane "I can't do it" because the driver doesn't realize what the card can do. (This can happen because the video driver you use might come with your operating system, before you bought the new video card.)
4. Your video card cando the trick, but the driver has a bug. The driver will tell X-Plane "I can do it", but when X-Plane says "go and do it", the video driver will crash your whole computer. This happens when drivers are buggy and can usually be fixed by getting newer drivers.

Something to note about this last case - we only crash if X-Plane actually says "go and do it". So when we release a new version of X-Plane that utilizes new video driver tricks...

• Some users have cards that can't do it and will see no change.
• Some users have cards that can do it, so they see the new feature.
• Some users have cards that can do it but old drivers and see no change.
• Some users have buggy drivers and see a crash for the first time.

GLSL shaders is a certain way to use the pixel shaders built into some cards. (GLSL is an interface and language to talk to those shaders.)

GLSL shaders are definitely not required for X-Plane 860. If you don't have them, X-Plane will run the way it always did.

But if your drivers are buggy and crash when GLSL shaders are used, you will need a software update to get good drivers. (There is a way out of this...if you really can't get a driver fix, there are command-line options that will tell X-Plane "don't use this feature even if the card has it".)

Virtual Memory - a precious resource?

Traditionally it always has been real memory - system RAM or VRAM - that's been most important to the flying equation. But recently virtual memory has been a scarce resource. What happened?

To understand this situation, consider X-Plane 6 vs 8. Back in the X-Plane 6 days, a typical system might have 256 MB of system RAM, 16 MB of VRAM, and 2 GB of virtual memory* for X-Plane. That's a ratio of 8:1 virtual to real RAM and 128:1 virtual to VRAM.

These ratios are actually pretty useful. At any given time only part of the loaded scenery is visible, so only part of it needs to be in real RAM/VRAM. So having that extra virtual memory lets us load a big chunk of scenery at a time, rather than having a lot of complex details to load tiny bits of scenery.

Today's computers are a bit different. 2 GB of RAM is not uncommon...that'd be a ratio of 1:1! And most gamers cards have 256 MB of VRAM now for an 8:1 ratio with VRAM. 512 MB cards are coming out and nVidia's monstrous 8800GTX comes with (gasp) 768 MB of VRAM! Insanity!

The problem is: RAM and VRAM are getting larger, but virtual memory is not! This means the ability to have the part of the scenery you don't see in virtual memory is getting more and more difficult.

Why can't we get more virtual memory? Well, the problem is to get more virtual memory we need 64-bit CPUs, 64-bit operating systems, 64-bit drivers, and 64-bit applications. That's a lot of parts that all need to be 64 bit and means a full computer upgrade and motherboard upgrade. Of the 5 machines Apple sells right now, only one is 64-bit, so even some of today's fastest machines aren't 64 bit. That's slow adoption.

So in the meantime we're adjusting X-Plane's strategy to deal with increasingly limited virtual memory. Back in X-Plane 6 it was acceptable to leave all objects their textures cached in virtual memory for later use (which sped up reloading of scenery).

X-Plane 860 (coming soon to a beta near you) will change this - unused textures and objects will be fully purged, which will hopefully address the problem of running out of virtual memory during long flights over lots of different custom scenery.

* 2 GB? Well, technically an application can have 4 GB of virtual memory, but the OS keeps some for itself. Some OSes take 2 and leave 2, some take 1 and leave 3, but even if we had all 4 GB of virtual memory for application use (and we don't - the graphics driver steals some too) we'll have 4 GB machines soon, so virtual memory is disappearing.

Scenery Polygons - Part 1

X-Plane 850 introduced some new polygon features that are worth looking at. Polygons are always legal in overlays, which makes them particularly flexible.

A polygon is any DSF entity described by one or more rings of points. A polygon's look is defined by its artwork file, which also constrains its properties. Polygons may:

- Be draped, meaning the polygon in the DSF does not have altitude information, but instead takes its height from the underlying mesh. A non-draped polygon has altitude information. (Only draped polygons should be used in overlays because a non-draped polygon might not match the base mesh correctly. You can't know whether a user has the 7-DVD DSF scenery, or old ENV scenery, or the older US DSFs.)

- Be curved (via bezier curves). This is only legal in some polygons.

- Have holes: some polygons can have additional interior polygons cutting "holes" in them.

X-Plane 8 shipped with one original type of polygon: facades. Facades are draped polygons with no holes or curves. X-Plane builds a building along the perimeter of the polygon. Facades were used heavily in the original US DSF scenery, and are useful for airport terminals, and even possibly fences.

X-Plane 820 added two new types of polygons: beaches and forests. Beaches are non-draped, non-curved, no-holes polygons that add a strip of beach texture between land and water. As mentioned above, I don't recommend using them in overlays because they are not draped. (They are legally allowed in overlays but the chance for ugly results is large.)

Forests may have holes and are draped, but cannot be curved; they fill in their interior with 1-4 polygon trees. We do not have any forest polygons in the current global scenery, but some users have built their own overlays to add trees to X-Plane using these polygons.

X-Plane 850 introduced the new apt.dat format with a number of new features. Rather than make the apt.dat file customizable (which would make the file format complex and change its fundamental purpose), we added new polygon types that let authors use the same facilities as apt.dat files have, but with a lot more control and flexibility. Three new polygon types implement some of the new X-Plane 8.50 apt.dat features:

1. Object chain polygons. You can make a polygon and X-Plane will string a series of objects along the polygon. The polygon is draped and may be curved, but may not have holes. X-Plane 850 uses this for taxiway lights, but this could also be used to plant trees along the edges of fields. (You could also use this to put streetlights along roads, but the road file format can do that already without adding extra polygons to the DSF.)

2. Painted line polygons. You can make a polygon and X-plane will drape a painted line along the ground. These polygons are draped and may be curved, but may not have holes. X-Plane 850 uses this for taxiway lines.

3. Draped polygons. You can make a polygon and X-Plane will fill it in with some kind of texture along the ground. These polygons are draped, may be curved, and can have holes. X-Plane uses these to make curved taxiways, but they have a lot of other possibilities since they provide a way to change the terrain.

I will comment more on draped polygons in a future blog posting, but one immediate note: before X-Plane 850 if you added an airport it was impossible to convert the terrain underneath to grass (from whatever terrain might have been present). With X-Plane 850 you can now make a draped polygon using a grass texture and a DSF overlay with the perimeter of the airport and thus "patch" the texture of the mesh to look like grass.

This technique is not as good as the grass in the native airports for four reasons:
- Draped polygon performance is slower than the mesh itself - I'll comment about that later.
- Our DSF creation program flattens airport areas - a draped polygon doesn't so there can be SRTM DEM noise that makes the airport area too bumpy to use.
- The DSF terrain grass can have a soft border, but right now draped polygons always have a very sharp border.

Draped polygons still represent a better option than putting the runways over the existing terrain though.

DSF Object Order is Not Draw Order

The order objects are listed in a DSF file (either the OBJ definitions or the actual OBJ instances) is not the same as the order X-Plane will draw them! X-Plane will change the order to maximize frame-rate, and the way it organizes them has changed in 850 (and will change again in futur versions).

Until X-Plane 850 there was no way to control the order of objects (although some packages do rely on X-Plane 840's behavior and now look funny in 850). But with 850 there is a clean way to control draw order that will work well into the future.

Starting with X-Plane 850, there is a new command ATTR_layer_group...it let's you override what part of the rendering process your object is drawn in, which is useful in a number of cases. Here's how it works:

X-Plane draws the scenery in a series of steps or "layer groups". Because of the way OpenGL transparency and polygon-offset affect Z buffering, X-Plane must draw the terrain first, all decals over the terrain second, 3-d buildings third, and anything translucent (clouds, smoke puffs, etc.) last. Layer groups organize all of the scenery into these catagories.

Objects are normally drawn in the "objects" layer group, which is intended for 3-d buildings, static airplanes, jetways, and anything else you might model with an OBJ. However ATTR_layer_group will let you specify that some objects be drawn earlier or later than others.

The command's syntax is:

ATTR_layer_group objects 1

Where the name ("objects", but others are allowed - see the OBJ spec) specifies a group, and the number makes the object be drawn after (positive numbers) or before (negative numbers). Objects with the same group and number are drawn together (in an unspecified order), but X-Plane goes by the numbers.

So for example if you want to ensure that a transparent hanger is drawn after a static plane, use ATTR_layer_group objects 1 on the hanger to draw it after all other objects. To draw some apron lines before the terminal, use ATTR_layer_group objects -1 to draw before buildings.

A few other tips:

• Try to use as few offsets as possible - e.g. try to put all "draw last" objects into the group objects/1 - rather than using a different number for each.
• Avoid using layer groups when they are not needed - they inhibit X-Plane from optimizing framerate.
• If you do not use a layer group, but do use polygon offset, X-Plane sets the layer group to objects with a negative number. This is inhibited when you specify the layer group yourself, so be sure to use a negative offset layer group for polygon offset!
• Try to organize your textures so that one texture is not used in multiple layer groups. For example, if you have translucent buildings that must be drawn later, group them in their own texture.
• Related - try to keep polygon-offset geometry (pavement markings) in their own texture and objects. Share one texture for all markings, but don't put the markings and object together.