Please read the requirements below twice – this is a very particular setup I need. To run this test you must have either:
- A functioning hackintosh running the latest Mountain Lion release (OS X 10.8.x) or a functioning Mac Pro running the latest Mountain Lion release (OS X 10.8.x) and
- An NVidia 560,57,580 or 660,670, or 680 desktop GPU in that machine and
- The computer must also be set up to run of Windows Vista or Windows 7 in Bootcamp and
- You have or are willing to run the 10.20 beta (at least as a demo and)
- You can run command-line fps tests if given instructions.
Please do not reply to this if you do not meet all three hardware requirements; I am looking for someone who can do a clean apples-to-apples comparison of NVidia driver performance between Mac and Windows.
Please do not comment on the post if you do not meet these requirements; I am going to clip the comments pretty tightly on this one.
EDIT: thanks, but a user already sent me the test data I needed!
I’ve seen a few bug reports complaining about ‘flicker’ with HDR enabled. It took me a few tries to understand that the users were not actually reporting Z-Thrash (which is what I think of when someone says ‘flicker’, but were actually reporting temporal anti-aliasing of anisotropic meshes like roofs and roads.
Ants are alienating an icy tropical metro what now?!?
Sorry, graphics programmers have lots of big words for things that aren’t actually that complicated. (Seriously, we call a daytime texture an “albedo”. Who is Mr. Bedo anyway??) But basically the issue is this:
- We have something that appears long and thin on the screen, like the roof of a far off building (wide, but not tall, in pixels) or a road (again, wide, but not tall – a road might be 20 pixels wide but only 1 pixel tall on screen). Anisotropic just means different lengths in different dimensions, more or less.
- The road or roof will be rendered in a stair-step manner, as the graphics card tries to approximate a diagonal with pixels.
- As the camera moves, which pixels form the stair-step will change every frame, causing parts of the road or roof to flicker into and out of existence on a per frame basis.
Going for a Swim
In the old days, this effect used to be called ‘swimming’. A diagonal line would appear to ‘swim’ as the stair-step pattern changed as the camera changed. The swimming was annoying, but if you had a lame graphics card, you could live with it.
The problem is that in X-Plane 10, a lot of the meshes we draw are a lot smaller. As we build more 3-d detail and improve the engine to draw more detail on screen, the result is a lot of really small things. In X-Plane 9 we could draw 5-10k objects; now we can draw over 75k objects. That means that individual objects on screen may be 1/10th of their size (since there are more of them).
So instead of having big objects with big triangles that ‘swim’, we have tiny triangles that flicker out of existence entirely.
Anti-Aliasing 101
One reason I haven’t blogged about this before is because there are a ton of different full-screen anti-aliasing technologies out there and the prospect of explaining them was daunting. Fortunately Matt Pettineo did an awesome job with this post. Go read it; I’ll wait here.
The main idea is that full screen anti-aliasing draws everything bigger and then down-sizes it to get softer edges. Diagonals don’t look stair-stepped, and a tiny roof won’t flicker into and out of existence because relative to the larger size that it was drawn, the roof is no longer tiny. In other words, 4x MSAA makes everything 4x less tiny from a perspective of a triangle being ‘too small to not flicker’.
The second reason why I am getting bug reports about flicker (besides a larger number of smaller triangles) in v10 is that HDR mode doesn’t use conventional MSAA. For various technical reasons, MSAA works poorly with a deferred renderer, and HDR is a deferred renderer. So like many games today, X-Plane’s problem is to anti-alias without letting the hardware do it. If you’re used to 16x MSAA from your graphics card, HDR with no FSAA is a rude surprise.
Current Option Number One: FXAA
FXAA is an anti-aliasing shader written by Timothy Lottes at NVidia. FXAA is typical of a whole category of anti-aliasing solutions in that it is a post-processing solution – that is, it takes an aliased, jagged image and attempts to smooth out the image after the fact. (MLAA is also in this category.)
FXAA has a few things going for it that are good:
- It’s very fast. The cost of enabling FXAA is very low compared to other anti-aliasing algorithms.
- It doesn’t consume any extra memory or VRAM.
- It produces smooth diagonal lines, more so than lower-levels of FSAA.
It does, however, have one major down-side: because it doesn’t actually draw the scene at a higher resolution, any mesh that is so small that it is flickering is still small, and thus it will still flicker. On any given frame, the roof will have no jagged edges, but the roof may simply not exist in some frames. If the roof isn’t drawn at all, FXAA can’t fix it in a post-process.
So FXAA is fast and cheap and makes still images look nice, but it can’t deal with temporal artifacts, that is, flicker between frames.
Current Option Number Two: SSAA 4X
4x SSAA simply means we draw the entire world at double the resolution in either dimension, and then down-size it later. Jagged edges become blurred in the down-size and thus aliasing is reduced. (Nerd note: when technical papers talk about OGSSAA, they mean ordered grid super-sampled anti-aliasing, which just means the image is bigger. 🙂
The up-side to SSAA is that it reduces flicker. Because the drawn image is bigger, very small elements won’t flicker (since they are bigger when drawn).
The down-side is the cost: 4x SSAA is the same as doubling your screen res in both dimensions. And if you’ve experimented with monitor resolutions, you know that once you are GPU bound, doubling the resolution in both dimensions uses 4x the VRAM and cuts your framerate to a quarter of what it was.
So the big problem with 4x SSAA is cost. Since we’ve improved HDR performance in 10.10r3 I’ve seen more users reporting the use of 4x SSAA. But it’s not cheap.
Newer, Better Options
I have two new tricks for HDR FSAA that I’m hoping to roll into 10.20. (They’re new to X-plane; I am sure someone else has coded these things in other games before.)
First: FXAA and SSAA can be used at the same time in the engine, for better quality than either can provide on their own. SSAA does better at fixing temporal artifacts like flicker (because it makes things ‘4x bigger’ relative to the size at which they flicker) but FXAA does better at making diagonals ‘less jagged’. Now you can have both. (10.20 features a newer version of FXAA.)
Second: I realized that our aliasing is anisotropic (there’s that word again) meaning it’s not the same in both directions. X-Plane’s worst aliasing comes from long thin horizontal screen elements like roads, and roof tops. Therefore having more anti-aliasing vertically than horizontally is a win.
So rather than just have SSAA 4x (which is twice as big horizontally as vertically) we can now do 2x (only vertical) and 8x (2x horizontal, 4x vertical). This provides a range of options; 2x SSAA will be affordable to some users who can’t run 4x SSAA at decent framerates. 8x SSAA will provide anti-flicker that should be as similar to non-HDR with 16x MSAA for urban scenes, for those who have a big new graphics card.
I posted a set of technical test pictures here.
What about TXAA?
NVidia has announced a new anti-aliasing technology, called TXAA. At this point there isn’t enough technical information published about it for me to comment meaningfully on it. My understanding is that TXAA is not yet available for OpenGL based games.
I can say that in the future we will continue to try to adopt the best anti-aliasing technology we can find, and the problem X-Plane faces (anti-aliasing for a deferred renderer) is not at all unique to X-Plane, so it is likely that there will be good solutions forthcoming. Far smarter minds are working on this problem at ATI and NVidia as we speak.
First, for the plugin authors: I am hoping to start a 10.20 beta for 64-bit in weeks, not months. I don’t know how many weeks it will be – there’s a huge potential for variation, but if you maintain a plugin, be aware that you’ll be able to actually test your plugin against a 64-bit X-Plane this year.
At this point we have launched X-Plane, 64-bit-style on all three operating systems. That doesn’t make it beta-ready but we have a heartbeat.
X-Plane 10.10 is final, and we may cut a small bug-fix patch (10.11) before we go into 64-bit. We have a handful of lower-priority bug fixes that we kept out of 10.10 for stability that we need to release at some point; the plan hasn’t been finalized.
Mac and 64-Bit: Not That Fast
So once I had a 64-bit X-Plane running on my machine, I did the obvious thing: crank the settings through the roof and see what happens. And I can now report the results:
Very low framerate.
The problem is: my machine was very close to maxed out with 32-bits. When I was able to crank the settings beyond where I could before, I simply overloaded it. Too many objects, too many textures, too many vertices, too much stuff. It’s a 2008 Mac Pro with a 4870 – not a spring chicken.
I mention this now because:
- The overwhelming majority of users telling us they want 64 bits are Mac users. On 64-bit Windows OSes, X-Plane has significantly more address space headroom, so you have to push the sim a lot farther to run out of memory.
- Macs just aren’t that fast. You either have a laptop (highly constrained by the need to be power-efficient) or an iMac (power constraints and no update for over a year) or a Mac Pro (with the best graphics card two generations old and no real CPU update in a while).
In other words, my Mac may be older and slower, but the very fastest ones aren’t that fast. There is no Mac equivalent right now to an Ivy Bridge i5 or i7 with a GeForce 680.
So while you may be hitting address space limits and crashing on your Mac right now, you may not have that much hardware budget left over, and it may be a short trip from 64-bits to finding you’ve simply maxed out your hardware.
It’s All About the Watts
One last thought on Macs falling behind Windows gaming machines: while this used to be a function of technology it’s really become a race with only two factors: watts and time.
- The older a model gets, the farther behind the curve it is. So the Mac Pro is really behind due to being age constrained; if they update it with a current-gen desktop GPU and an Ivy-Bridge based Xeon CPU it won’t be cheap, but it will be competitive. For desktops the big issue is one of cost: you can get the latest mobo at any time for Windows and a game machine is significantly less than a Mac Pro.
- Watts: how much GPU power you get is a function of the power budget of the card, and both the iMac and laptops are constrained relative to desktop machines. The new Retina-Book MacBook Pros are nice, new, top of the line laptops, but they are also using the GeForce 650M, a decision to trade off some GPU power for battery life, heat dissipation, etc. There will inevitably be an AlienWare laptop that ways 12 lbs, burns through its battery in five minutes, but ships with a bigger mobile GPU for better performance. I’d rather use the lighter laptop, but my concern is traveling with my work, not flying.
My point here is: these two factors (revision time for models and power use profile) are unlikely to change any time soon – they are fundamental to Apple’s business model. So Mac users, on average you are never going to have the same performance options as your Windows brethren.
Edit: see the end of the article for a GUI tool to manage joystick permissions.
I’ve already briefly discussed some of the changes necessary to get joystick devices working properly but I thought it’d be a good idea to consolidate all information into one post for easy reference as 10.10 is nearing it’s release to the masses.
First, why the change? In the past we used the “joystick” interface to joystick devices on Linux. This interface is extremely basic and is really only useful to games that require minimal knowledge of the actual hardware. X-Plane really does not fit this specification at all. X-Plane needs to work with the spectrum of hardware from the most basic one axis trim wheel to the most complicated home-built cockpits that have dozens of axis and literally hundreds of buttons and switches. In order to support this properly, in 10.10 we’ve switched from using the “joystick” interface to using the “input” interface. This gives us ALMOST the same quality of low level access to the hardware that we get on Win/Mac. The problem with using the “input” interface is that almost anything can be an input. Your keyboard and mouse for example are “inputs”. As linux is a multi-user operating system, there are permissions concerns regarding input device reading. You wouldn’t want another user snooping on your keyboard as you’re typing credit card numbers would you? Many Linux distros by default restrict access to these devices with some exceptions handled in ACLs. If the device LOOKS like a joystick, anyone’s allowed to access it since the security risk associated with joysticks are pretty much zero. But the definition of a joystick is something that has two axis and some buttons. Therein lies the problem. Rudder pedals don’t have any buttons. Trim wheels don’t have any buttons either and they only have one axis. Because of this, the ACL for the devices does not kick in and you now need root access to read from the device.
The solution…run X-Plane as root! I’m joking though some people will have no problem doing this. If you’re cool with that, be my guest but it’s generally not regarded as a safe way to run a system. For the rest of the population, there are rules than can be created that will detect your hardware and automatically set the permissions appropriately so that X-Plane can access the hardware. These are called UDEV rules. For a typical Linux user, creating a UDEV rule should be walk in the park but for a novice it might seem tricky. Luckily, it only needs to be done once and will work for good.
A big thank you goes out to Bill Good who is a member of the X-Plane.org community. He put together this tutorial for you guys to benefit from.
- This is an optional step but it really makes things easier. Each piece of hardware has a Vendor ID and a Product ID. These are called the VID and PID in industry. These two ID’s together are used to detect a device’s existence. You’ll need to know the VID and PID of each device that you care about. To determine this, you can get a tool called “lsinput” which makes this a bit easier. Just run “sudo apt-get install input-utils” on a debian based system. If you’re Red Hat based, i’m sure you can run the similar “YUM” command.
- Run “sudo lsinput” which will list all /dev/input/event ‘s that are attached to the system. Find the hardware that you care about. Here’s a sample output for a Saitek Pro Flight Rudder. Notice the Vendor and Product lines which have hex values of 6A3 and 763 respectively. That’s what we need.
/dev/input/event6
bustype : BUS_USB
vendor : 0x6a3
product : 0x763
version : 273
name : "Saitek Saitek Pro Flight Rudder "
phys : "usb-0000:00:16.2-4.1/input0"
uniq : ""
bits ev : EV_SYN EV_ABS
- Create a file called “99-X-Plane_10_Joystick.rules” in your /lib/udev/rules.d/ directory. I’m not sure if this path is distro specific. You may need to look up where udev rules go on your distro. EDIT: Users report that a more appropriate path may be “/etc/udev/rules.d/” which has the added benefit of being a location that gets grabbed by backups. Either path will work fine however.
- In the 99-X-Plane_10_Joystick.rules file, create one entry for each device that you wish to include. Put them all in this file…each hardware entry on its own line. Only the ATTRS sections need to be set by you, the rest is boilerplate. Notice the Vendor and Product values of 6A3 and 763 from before in the sample below (Make sure to scroll horizontally. On smaller monitors, the whole string may not be visible).
KERNEL=="event*", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666"
- The last step requires a restart of the system. There MAY be a subsystem that can be restarted instead of taking the whole system down but i’m not aware of what that may be so it’s best to just restart the whole thing.
Update: One enterprising Linux X-Plane user has written an open source GUI tool to manage joystick permissions. Here it is!
[Scene opens with a joystick being thrown across the room in frustration. Camera angle is from the ceiling looking down. A rotating and twisting view creates tension as it centers on the joystick, laying abandoned on its side as the dust settles. Cut away to a different angle. In the background is an iMac with Google Chrome open in the background just barely in focus.]
[In walks developer Chris Serio wearing a pair of Ray-Ban sunglasses. He nudges the joystick with his boot before crouching down and removing his sunglasses to get a closer look.]
Chris: “Looks like someone really had it out for this Joystick”
Ben: “Yeap…tossed it like a salad at Denny’s. What do you think ticked them off?”
Chris: “I bet Google’s behind this somehow…”
Ben: “Google? Really? I thought their motto was to do no harm?”
Chris: “On the contratry…They’re involved in everything!”
[Chris stands up and walks over to the computer…the camera zooms in as Google Chrome comes into focus on the screen]
Chris: “You see this? Chrome…that’s not a coincidence. I want the computer’s ip address…run it through CODIS. Bag it and tag it”
[The camera moves back and zooms out as Chris pulls his sunglasses from his pocket, placing them on his face as he pauses to speak]
Chris: “This Joystick killer’s about to get…..yoked”
[Cut to opening credits as The Who’s “Won’t Get Fooled Again” plays loudly]
Ok so perhaps I’ve seen too many episodes of CSI in my time…but sometimes I must say I do feel like more of a detective than a developer.
The latest weirdness with joysticks is that on Mac only, sometimes they do not seem to work at all. In the log, you’ll see an error message stating that the device could not be opened. I’ve seen it myself before and it’s odd because typically device access is shared between processes. Imagine if your keyboard only worked in your word processor because it demanded exclusive access and none of the other applications on your computer could use it once the word processor was opened. That’d be silly right?
I started killing processes on my system one at a time until the joystick finally started working again. Killing Google Chrome is what did it. Why on earth would a web browser be touching my Joystick hardware?!
After a bit of research and a run through Chrome’s source code (isn’t open source great?), I discovered a new system in HTML5 compliant browsers like Chrome called Gamepad. Gamepad allows new HTML5 pages to access your joystick hardware! Because of the Olympics, the daily Google Doodles have been little mini games which are stealing Joystick access! So Olympics + HTML5 kills Joysticks in X-Plane….amazing.
The solution is a simple change for them. They just need to pass a different flag so that they share the device with other applications. I’ve already filed a bug and spoken with the developer and the fix will likely be in Version 22 of Chrome but for now, make sure your browsers are closed if you appear to be having intermittent Joystick issues on Mac.
Sometimes reality is stranger than fiction…
***EDIT*** I do have to say, I got an immediate response from the engineer in charge of this Chrome feature and within an hour the bug was fixed and checked in for release in future versions. I can’t ask for better support than that.
As you are hopefully already aware, the Joystick subsystem of X-Plane was completely rewritten for X-Plane 10.10. It uses a much lower-level method of communication to essentially talk directly to the devices so that we have complete access to their capabilities instead of being limited to what a “middleman” layer of software feels like telling us…which is how things used to work.
While most of the bugs have been fixed as of 10.10Beta 4, there still remain a small subset of devices that are still having problems. Let me list the known open issues:
- Even after calibration, some devices still show their axis max limited to about 75% of what it should be when viewed on the Axis tab of the Joystick Dialog. In other words, pull the yoke toward you and it goes to 0, push the yoke away from you and it goes to 75% instead of 100%. This is not a joystick bug at all but in fact a UI bug that’s been around all along but just never visible until now. This has been fixed in 10.10Beta 5 which is coming soon. You can also go to the “Null Zone” tab and see that your axis does in fact have it’s full range of travel.
- Some hardware does not appear at all on Linux. This is not a bug! This is a security feature of the Linux operating system. The problem is, Linux is a multi-user operating system and it has to worry about permissions to devices that are attached to the system. Take a keyboard for example…imagine if another user logged in could see everything you were typing because he had read permissions on your device! Linux locks down permissions on devices that are not part of an exception. The way to create an exception is to create a UDEV rule. If you don’t know how to write a UDEV rule, google it a bit..they are not very complicated for the average linux user. If you’ve chosen linux as your operating system, we hope you possess the skills to configure it. Here’s a simple sample rule:
KERNEL=="event*", ATTRS{idProduct}=="0bd4", ATTRS{idVendor}=="06a3", MODE="0666"
Here the VID is 0x06A3 and the PID is 0x0BD4. These are unique codes that identify that brand/model of joystick and the rule says “When you see this device, chmod 666 it.” One way of finding your VID/PID is by doing “lsusb -n”.
- Some devices have hat-switches that appear to “stick” in the ON position. This is fixed in 10.10Beta 5 as well.
- Last but not least, there are some devices that have particular AXIS or HAT SWITCHES that simply do not work. So far, I’ve seen a Logitech G25 clutch pedal and a Logitech G940 hat switch that doesn’t work. It works in the windows calibration screen as well as X-Plane 10.05R1 but not in the latest version.
Here’s where you guys come in. If you have one of those two Logitech devices, please let me know if yours is working just fine or if you have the problem as well.
I’m also interested in hearing about other devices that are having the #4 issue as well.
Lastly, if you are having any other kinds of Joystick problems that do NOT exist in 10.05R1 but that DO exist in 10.10 that haven’t already been mentioned, please let me know.
You can file a bug and please include a Log.txt file from 10.10Beta 4 as well as a description of what’s not working properly and on which device.
X-Plane 10.10 Beta 3 is here. To avoid having to type it each time, all of the info about betas is now on the release notes page here. Please read it carefully! Please: no bug reports on the blog, only on the bug report form!
You may have noticed the large number of joystick-related bugs in X-plane 10.10, something that is unusual for X-Plane betas. There is a reason for this: Chris totally rewrote the joystick IO code from the ground up for 10.10. We had been living on the same old dubious code for perhaps 5 years before; the new stuff is literally brand new.
Chris is working through the joystick bugs at a pretty quick pace. We will continue to push betas frequently as long as there are bugs that interfere with us collecting other bug data (e.g. crashes, joysticks totally inop, etc.); then we’ll slow the pace of betas down to get more fixes in per beta.
What possessed us to send Chris off into HID land on a quest for new IO code? The new IO code is meant to support a number of features, a few in 10.10 but most coming in a future build:
- Hot swapping (here now).
- Correct hat switch operations (here now).
- Preferences bound to more than one stick without resetting (here now).
- Automatic configuration (coming in the future).
- Better descriptions of the hardware in the UI (coming in the future).
- Ability to easily open source the Linux IO code (coming in the future).
The new code sets up a unified interface to the hardware, with the hope of sharing configuration info and being able to open source the low level IO code.
The long term goal is to make it really easy to work with X-Plane joysticks: plug it in, go through the absolute minimum configuration just once, and you’re flying.
What, You’re Not Root???
Linux nerds: X-Plane 10.10 moves from the joystick API to the input API for joystick IO.* The input API gives us a modern interface with better meta data about the hardware. However we have seen cases where the access control list on the “event” device for the joystick isn’t user-readable even when the “joystick” device is.
Chris is still discussing what we can be done with knowledgeable Linux types, but my view is: this seems like a bug. If the device is safe for users as a joystick, it’s safe as an input event source, and it shouldn’t be necessary to make a udev rule and/or chmod the device entry to use the joystick-type device. So perhaps at some point we can push corrected udev rules up into upstream distributions.
But this isn’t something that Chris and I have any expertise in; if you are a Linux X-Plane user and have expertise in the area, please keep an ear open for when we get closer to a resolution on this issue.
(In the meantime, you may have to take the sudo-hammer to your joystick in 10.10.)
* Our preferred interface would be a HID interface, but we don’t have our own HID descriptor parser; we use the OS X and Windows one. There are two show-stoppers to speaking raw HID. One is the lack of a parser on Linux and one is that the raw HID-as-report device has similar permissions problems to the ones mentioned above for weird joysticks, except the permissions are root only all the time.
So some day in the future perhaps we’ll get to reading raw HID (which would give us perfect similarity to Mac/Win) but for the time being we expect to ship on the unified input interface.
***CHRIS’S EDIT*** I _think_ I’ve squashed all kinds of Joystick related crashes and Joystick calibration issues. These are issues where the stick would not move smoothly from one end of travel to the other. I also think I’ve squashed issues where certain devices/axis were just not showing up. If you have a device that’s still having problems with Beta 3…PLEASE FILE A BUG REPORT. I definitely want to know about it. Always include a Log.txt from a sim run that had the device attached.
This post will pretty much only be of interest to Linux users – everyone else, talk amongst yourselves. Topic of discussion: X-Plane.com is neither a plane nor a communist. (Sorry, work on the road processing code has drained me of any remaining sanity.)
Linux History
The brief history of X-Plane for Linux is that Joshua Wise ported X-Plane to Linux a while ago because he felt like it (and being too young to drive at the time, apparently had some free time). The Linux port was never a commercial effort. – Laminar Research didn’t say “we’ll make a ton of money by porting to Linux, so let’s hire someone”. It just sort of happened. (Well, I wasn’t in the room so I don’t know exactly what was said.)
Linux has steadily represented about 5% of our user base from that point on, and this gets to the “commercial problem” of Linux: even with the work we do to try to keep platform specific code in X-Plane to a minimum, Linux sales don’t justify the development cost to maintain the platform.
Yet there still is a Linux version of X-Plane. We keep renewing the Linux port for “one more version” because while the Linux community doesn’t buy a ton of copies of X-Plane, Linux users do contribute in an outsized way by providing code back to the scenery tools and other development efforts. In other words, the Linux community doesn’t contribute dollars, but they contribute a lot of code.
Code Contributions
This came up during the X-Plane 9 and 10 Linux discussions. Our primary request to Linux users has been “please support each other”. There are too many Linux distributions for us to provide support; our dedicated support staff does not even have Linux expertise, so Linux support immediately hits engineering.
While a number of Linux users have really done a great job of helping other users out, another issue came up. One of the ways we try to minimize Linux-specific costs is to keep the OS-specific code very basic and rudimentary. In the past we’ve taken patches from users to fix OS specific bugs, but this is an awkward process at best.
Some Linux users asked if we could find a way to release source to the OS-specific parts of X-Plane so that they could improve the Linux-specific code (and thus the platform-specific experience) themselves. Right now this is a very awkward process: I have to tell the user “give me a snippet that does X” and then hope that I can get the snippet integrated and tested on my own.
One of the suggestions that came up at the time was to separate out some of the code that abstracts the OS/hardware so that Linux users could patch it more easily.
A Hard Abstraction
Separating out the platform specific code is a good idea, but it wasn’t one we were going to drop everything to pursue – if we did, the end result would be no improvement to X-Plane after some number of weeks of heavy development. Instead, we are slowly moving the code in this direction as we work on it.
The first code to get a work-over is the joystick code; Chris has been refactoring the joystick code for a few weeks now. 10.10 won’t show you any new behavior; it runs the existing UI on top of new low level code. Once we are sure this works, Chris can implement a bunch of new joystick UI features on top of the new low level code quite easily.
The new joystick code separates out the OS-specific joystick interface code from the rest of X-Plane. In the long term, this will make it practical for us to share the hardware abstraction code with users as source, take patches, and even allow developers to swap it out on their local development machines via a shared object. We’re not there yet with this level of flexibility, but the new code makes these things possible.
You Can Keep Your Hat On
There is one immediate win to the new code that will be apparent to Linux users in X-Plane 10.10: the new code (which is based on input.h instead of joystick.h) recognizes hat switches as a set of buttons, rather than a pair of axes; this is almost certainly better from a UI configuration standpoint.
I meant to post this before, but: the new Catalyst 12-3 drivers fix a number of Radeon HD 7xxx-specific artifacts with X-Plane: incorrectly cut-out tree billboards and flashing triangles. So while I suggest latest drivers anyway, this update is particularly useful if you have a 79xx.
Just a quick tip on tuning X-Plane’s rendering performance: if you see your fps start off strong and then drop over time to a crawl, with low GPU, turn down the cars.
Here’s the problem: cars are spawned over time. The way the car engine works is that X-Plane comes up with a budget for cars based on rendering settings, and adds a few more every frame as long as it’s under budget; if it is over budget it simply doesn’t replace cars that are killed by being too far from your plane or reaching a dead end.
It can easily take several minutes for car traffic to build up.
And the thing about the car traffic is: it’s incredibly CPU intensive. This is something that I am working on and it may get better for future patches, but for now just consider this: a reasonable setting for cars (for your computer) should be based on the framerate after several minutes, not the one you instantly get when there are virtually no cars!
