For those of us who do not use the keyboard and mouse with X-Plane, datarefs and commands are required for a proper experience. For the payware aircraft that rely on standard X-Plane datarefs and commands, full compatibility is available out of the box. As payware aircraft become increasingly complex, they increasingly require non-native datarefs to achieve full compatibility with external hardware. I have started to create a list of payware aircraft that provide datarefs or out-of-box compatibility for customers. For the time being, I recommend avoiding those aircraft vendors who do not provide full lists of datarefs.
Over the past week, I revamped the code for the Arduino switch box project I started in April of last year. Before I talk about the improvements in XArduino 2.0, it is important to understand the motivations behind these changes. At some point between April and the end of the 2012, I stopped using my Arduino switch box due to performance issues. Those issues were as follows:
Generally poor performance causing low FPS
Intermittent lag between switch action, and dataref change or command execution (multiple seconds)
High frequency of malformed output
I’ll talk about how I addressed each of these problems below.
Bitwise functions in lieu of string manipulation
While comma-separated text may offer a simple solution for spreadsheet standardization, parsing comma-separated data every frame can cause some lag. In the first release of XArduino, the output looked something like this:
Once the “H” was detected, the Python code would read all the data between that letter and the carriage return at the end of the string. Next, Python would check the integrity of the string by ensuring there was a comma every other character, and the line length was the appropriate number of characters. Each value in the string represented the switch position (0 = first position, 1 = second position, etc.).
Only one piece of this methodology was reused in XArduino 2.0. The string still starts with a single letter and ends with a carriage return, but instead of displaying each switch position in a comma-separated string, the switch positions are stored in a 16-bit number on multiple lines (if necessary). Multiple lines are necessary when using more than 16 two-position switches because the Arduino Uno and Mega are both limited to 16-bit numbers. The switch positions are decoded from the number using bitwise operators.
Continuous output vs. event-driven output
In XArduino 1.0, a new line was outputted every 50 ms regardless of whether or not a change had occurred. In XArduino 2.0, a new line is only generated when a switch position changes. This prevents the intermittent, but significant, lag associated with Arduino’s internal caching mechanism. To deal with the limited potential for malformed lines, each time a change occurs, the string is outputted three times. Increasing the baud rate also helped deal with the frequency of malformed lines. Together, these changes also generally improved performance.
What’s new in XArduino 2.0
Improved performance by 50-100% (i.e. no measurable impact on FPS)
Allow multiple commands per switch position
COM port and baud rate set in configuration file instead of code
Moved from string-based output to 16-bit numbers
Fixed majority of malformed lines in communication between Arduino and pyserial
Fixed delay in switch command/dataref by preventing endless polling
Finally, AMD has released new drivers for all their cards, including “full support” for the Radeon HD 7900 series. I have yet to test these, as download speeds are hovering around 50 KB/second, but I will post results as soon as possible. It looks like X-Plane made it into the list of bug fixes:
XPlane: Textures no longer exhibit flicker and corruption
After successfully implementing switches, buttons, and LEDs with the Arduino microcontroller, I decided to take on servos. Please forgive my makeshift indicator, which was constructed using a post-it note! I am still looking for a good method for creating something more professional and open to suggestions. The code is good, but the aesthetics are still undoubtedly in the “proof of concept” phase.
As you can see, the servos will work out of the box for the most part. Each servo requires power, ground, and a digital pin. To compensate for the USB output, I drilled a circular hole using a 5/8″ drill bit. If you have more precise tools, you can make this as pretty as you want. Personally, I would have preferred the USB output extend from the rear, but to accomplish this we would need some kind of female-female 90-degree connector, or a larger project box.
Ben over at Laminar Research has taken the time to address the AMD performance issue again. Even though this doesn’t change much right now, I think this small amount of communication will turn down the heat a little. Here’s what was posted:
Finally, one last note on ATI Windows performance – I know everyone is itchy for an update, but here’s the thing: we have NDAs with AMD, NVidia, Apple, and Intel. Therefore when we get information from them, I can’t post it here. So unfortunately whether a bug is not being looked at, being looked at, understood, being fixed, or already fixed and just waiting to make it into some kind of release, I have to say the same thing: very little. I know that that’s frustrating, but I think we’re better off having close relationships with these companies and being able to solve these problems. If there’s ever a chance to put a work-around in X-Plane, we do that.
So I can’t give you any new news on ATI Windows performance, and I am sorry about that. I can only say that it is my top priority. [source]
In my HD 7970 travels, I recorded two short videos so users can see a comparison between HDR and non-HDR flying. This isn’t meant to be a direct comparison per se, but it will show how the HD 7970 is doing overall. The first video uses HDR with atmosphere scattering and FXAA post process anti-aliasing enabled. The second video uses 8x anti-aliasing with HDR disabled.
HDR with FXAA post process & atmospheric scattering
Filmed near KLXV airport, direct KDEN. Aircraft is Twin Otter by X-Hangar. While performance was so-so and artifacts were present during this trip, the simulator was usable.
Non-HDR with 8x anti-aliasing
Filmed over Lake Michigan after departing KORD. Aircraft is Challenger 300 by ddenn. While the 8x anti-aliasing outperformed HDR flying, the simulator froze about twenty minutes into the flight. Other than that, the simulator was usable, with so-so performance.
I realize it’s apples and oranges to a degree, but which do you think looks better?
After looking at benchmarks and reviews, I decided to purchase the XFX Radeon HD 7970. On paper, this thing is a powerhouse, and one of the best consumer-grade cards on the market. I don’t do any gaming per se, and will only use the card for casual video editing, and Laminar Research’s X-Plane 10.
For the past few months, I have been monitoring the myriad issues with X-Plane 10 and AMD’s Radeon HD 7970 graphics card. XP10 is a brand new piece of software, and the HD 7970 is a brand new piece of hardware. With any new software and hardware, issues are to be expected; however, it’s been three months, and very little has changed.
Neither X-Plane 10 ($80) nor the Radeon HD 7970 ($580) are cheap. Both involve substantial investment and dedication. With costs that high, the consumer expects high quality, compatibility as stated on the box, and excellent performance. If these expectations are not met, market forces should work their magic and force the hand of one or both parties. Unfortunately, we have not seen much movement on either front; although, we have seen a few updates from AMD, each one better than the last. At this point, we are now getting messages like, “The 7970 works flawlessly on every game except X-Plane 10.”
This leads me to the purpose of this article. We’ve heard various reports of “issues” with the HD 7970, but what is really going on? In spite of the various issues, what kind of performance can we expect out of the HD 7970 at this time? I’d like to attempt to answer those questions on a basic level, and provide some insight into the software, hardware, and growing image problems.
Personal Interactions with Laminar Research
First, let me talk a little about my personal experience with Laminar Research, which has been very good. Of all the bugs I’ve submitted, I’ve been contacted by Austin once, and Ben multiple times. For the most part, I feel Laminar has been very responsive to the bugs I’ve submitted. This is very important. People like updates on “their” bugs, even though it isn’t always practical from the development side. Overall, they are extremely smart and talented, and seem like genuinely nice people.
As a fellow developer, I understand the importance of good bug reports, especially considering the fact that X-Plane supports three operating systems. Without reliable bug reports, Laminar Research, Microsoft, Apple, etc., could not do their job. Many bugs are found prior to production use, but many more are found after release. It is the reason we release patches and updates.
Damage to the Reputation of Laminar Research & AMD
At this point, it is clear that there is some damage being done to both Laminar Research, and although inevitably less, AMD. The reason I say Laminar is enduring the most damage is because the HD 7970 and other AMD-based hardware work flawlessly and shine in tons of games. When users see their card working as expected in every arena except X-Plane 10, they will inevitably point a finger at Laminar Research.
Also, threads like this certainly aren’t doing Laminar any favors: . This thread regarding the HD 7970 was posted at the official X-Plane forum in January: . Although Ben Supnik addressed the bug with candor at the beginning of February on the X-Plane Developer blog, we haven’t heard much about it since that time. The last update came in the form of a blog comment in which Chris Serio basically restated what was in the blog post:
We don’t know if it’s a bug in the driver or not. We’re doing as much as we can to figure out the cause.
First, I’m not sure that is an acceptable answer after this amount of time, even if AMD is the culprit. People want details. People want to know that they are diligently working on this issue. Also, I don’t know how much longer this can go on without seriously damaging the reputation of X-Plane 10, which is an amazing simulator in every other regard. This is really a make or break moment for XP10, especially with the numerous FSXers leaving after the disappointing release of Microsoft Flight. If it is to become more successful, this issue will have to be wrapped up in the short-term—the very, very short-term.
General Performance Results
The link below is a spreadsheet that shows some basic observations and relationships between rendering settings and frame rates. To compute these results, we used the area around KJFK airport due to overall population density. The same overcast and broken cloud layers were present in every single test. I used Fraps to determine average frame rates, as well as the in-game frame rate indicator. In order to show the artifacts and flashes, we had to use Fraps, which causes frame rates to be reduced while recording. The performance results in the spreadsheet will be accurate, but please ignore the frame rates seen in the upper-left corner of each YouTube video.
Outside of the performance problems, the single biggest issue I saw was the presence of visual artifacts, flashes, and flickers on objects and various surfaces within X-Plane. This greatly impacts the XP10 experience, and seems limited to the HD 7970 card. I also have an HD 6870, and while I experience some performance issues, I do not see these kinds of artifacts and flashes.
Below are several videos, which show the type of flashes, flickering, and visual artifacts detailed in the performance spreadsheet. Each video corresponds with a note number on the spreadsheet (see the notes column on the far right).
The combination of default roads and very high distance detail seemed to exacerbate the flashes and flickering.
Changing the road setting from default to extreme, while keeping very high distance detail, seemed to reduce the flashes and flickering slightly.
The following combination of settings, which included the “default” road setting and “very high” distance detail, produced strange red flashes, flickering, and other visual artifacts.
Turning on HDR exacerbated the flashes, flickering, and visual artifacts in many instances. A sharper reduction in frame rate was also seen, which seemed to hover around 24 FPS with the following settings.
The settings here are the same as those in “Note 4,” except anisotropic filtering, which was increased to “4x (hardcore).”
Microsoft Flight & Flight Simulator 2004
On a side note, I also loaded up both Microsoft Flight, and the antiquated Microsoft Flight Simulator 2004. I jacked up every rendering setting I could find, and guess what? Both performed flawlessly. Now, I’m not going to switch to Flight or Flight Simulator 2004, but I think you see the point.
Well, as you could imagine, it’s very disappointing to write this article. I was hoping the first article would be more positive…maybe how to fly an ILS approach in XP10 or something similar! At the very least, I hope that Laminar Research is giving the problems with AMD and HD 79xx series video cards the highest priority. These issues need to be fixed before the cityscape and overpass bugs, if possible. It’s about making XP10 playable for everyone (i.e. making it truly stable). The cityscape nuance is certainly not mandatory, but something we like to call a “nice-to-have.” In my opinion, the overpass bug should also take a backseat to the AMD and HD 79xx bugs.
In the mean time, keep submitting bugs to Laminar Research and AMD, and don’t be afraid to express your frustration. They cannot do their job without feedback and bug reports.
Ben took some time to address the ongoing performance issues with cloud rendering, cars, and fill rate on Windows systems. If you have experienced related performance issues in X-Plane 10, I highly recommend reading this article. It is the first article that draws out a path forward. For example, it was discovered that parts of the OpenGL API are slower than expected on AMD hardware.
There are two related posts—one for the moderately technical user, and one for professionals.