X-Plane supports connecting your favorite real-world EFB app like XAvion, WingXPro, ForeFlight and FlyQ. This way, you can use your iPad or tablet just like you would in a real cockpit – display enroute charts, approach plates, with optional weather and traffic overlays.
This worked extremely well with the XAvion app, a Laminar in-house product, but for 12.3 I wanted to improve support for other popular apps.
Foreflight showed me where I was, and also some traffic diamonds around me, but synthetic vision didn’t work, relative motion and tail numbers on the traffic didn’t work, there was no METAR and the NEXRAD didn’t show either.
Getting synthetic vision to work required sending the AHRS data in a way modern EFBs understand. Austin had coded this in 2013 when the ADS-B receiver of choice was a little plastic box called Clarity, that when you pushed the on-off button too hard just collapsed on itself. We’ve had several that lost their on-off button after you turned it off a bit too vigorously.
This was before the Appareo Stratus, uAvionics Sentry and other popular devices existed.
It’s been 12 years since then and X-Plane still pretended to be this falling apart, overheating plastic box… And Foreflight would flat out reject anything that X-Plane tried to tell it.
Luckily, it is easy nowadays to support ADS-B and GDL-90 thanks to an open-source project called Stratux!
I started by turning X-Plane into a simulated Stratux rather than a Clarity. Added the new AHRS messages, support for barometric pressure, etc.
Now, Synthetic Vision on the iPad was working! Traffic had relative motion!
But the weather was still stubbornly refusing to show up, even though all the weather packets were absolutely according to spec, and parsed to readable METARS, etc…
And glued my DIY Stratux into the window of my Tesla and went to see a tower!
These towers are optimized for sending data upwards into the sky, so you have to get rather close to them to pick up any signal on the ground.
I found one, parked my car, and started recording:
Unfortunately, the first tower I went to only rebroadcast traffic, but did not send any weather!
So, I had to drive to a different tower, until I found one that gave me the weather:
Picture me, parked outside the airport gate, with this thing in the window with wires coming off of it.
About 10 minutes in, some people from the local helicopter medical airlift service come out and politely ask me if I need help. I convinced them that I had no nefarious intent, was not spying, and merely taking advantage of the good reception under the tower…
Spoiler alert: I did not get arrested that day, despite having what looked like a makeshift detonator in the window.
With a few Megabytes of recorded FIS-B messages, I set up my remote office, and started to analyze what the difference was between the messages X-Plane sent and the messages I recorded from the tower:
Turns out, X-Plane didn’t fill in some header data containing a 80ns timestamp that shows when the packet was received from the tower (not the age of the weather report, simply when the receiver picked up the packet, measured using the GPS clock of the receiver).
Once I added this missing data, the weather is accepted as valid by my real EFB!
And boy does this work now! Look at all this data going into ForeFlight:
Now, you can tap an airport in ForeFlight, and it will show you the METAR of the actual weather in X-Plane at that airport, correctly indicating it came from ADS-B:
These two aircraft are AI aircraft, and the thunderstorm cloud north of Greensboro really was there on that day, but what you are seeing is the weather recorded on our server, replayed by X-Plane, and transmitted onto the iPad by X-Plane, showing what the weather looked like that afternoon!
And here you can see it works great with user-defined weather as well! Frankfurt did NOT have thunderstorms like that. This is simply me starting X-Plane in EDDF and setting the weather preset to nasty weather:
All aircraft in the X-Plane 12 world cast a wake turbulence – a wing cutting through the air in X-Plane 12 leaves a vortex in the air that swirls inward over the wingtip, and sinks slowly as it dissipates energy over time. The strength of the vortex and its lifetime depends on the lift force generated by the wing (i.e. a wing that has to lift a 172 does not create a strong vortex, whereas a wing that supports a 747 surely does). Over the course of its life, the vortex sinks slowly and is displaced by the prevailing wind.
Flying through such a vortex can be dangerous! If you cross the vortex left by an airliner while flying a 172 yourself, be prepared to be tossed around or even flipped upside down. If you do the same with roles reversed, you might see a slight bump just enough to ripple the surface of your coffee (be sure not to do this in an A350 as spilled coffee can cause in-flight engine shutdowns).
Wakes left by AI aircraft
AI aircraft in X-Plane run the full flight model. That is, each wing is calculated using the same methods and with the same accuracy as for the user aircraft. Thus the amount of energy left in the wake vortex is clearly known, it just comes from the flight model. Therefore, if ATC clears that 747 to take off before you, be sure to stay above their flight path until you can turn away from it. For landing, stay above the preceding planes path and touch down slightly further down the runway than they did to stay safe.
Wakes left by online traffic, live traffic, and other plugins
For aircraft that are not run by the X-Plane flight model, such as other players’ aircraft from an online network, or real-world traffic injected from a plugin like Live Traffic using data from an ADS-B exchange, X-Plane makes a best effort guess based on the data provided by the plugin. The plugin can tell X-Plane how heavy the aircraft is, and its wing area and wingspan. In the absence of this data, X-Plane will fall back on a fairly conservative light aircraft estimate, assuming a Learjet-sized aircraft weighing 10 tons with a 12m wingspan. This means you are not going to get flipped upside down in your 737 if you end up flying through a wake left by an old plugin. This is to minimize user frustration with existing online flying plugins. Since the wakes are technically an extension of the TCAS override API used by plugins since X-Plane 11.50, all plugins that show traffic in X-Plane 11.50 are compatible with wake turbulence generation and will gain that base functionality automatically when used in X-Plane 12.
Wake turbulence data for plugin authors
Plugins can use new datarefs starting with X-Plane 12 to inform X-Plane of physical properties of the non-player aircraft that are then used for a more accurate strength and duration of the wake. By writing to the new datarefs, a plugin providing traffic data can upgrade from the “generic Learjet wake” to an accurate wake representative of the aircraft they are actually drawing.
Learn about wake turbulence avoidance
In X-Plane, you can cheat and make the wake left by an aircraft visible by having it drawn in the sky in a color scheme showing its danger (from red over orange and yellow down to green) so you can avoid it (or fly through it on purpose to experience the effect). Wake visualization is just one of the many graphical flight model outputs available. Press Ctrl+M to toggle graphical flight model output in X-Plane. By repeatedly pressing Ctrl-M you can cycle through all the visualizations available, while a small white label tells you what you are looking at. Keep toggling until you see “Wake Turbulence” displayed and marvel at the air disturbance waiting to make your day interesting.
You can also use X-Avion on your iPad to have wake turbulence danger zones visualized – this works in real airplanes using ADS-B data, and it works in X-Plane when driving X-Avion over network.
As you saw at Flightsim Expo, X-Plane 11.30 offers a wide range of new features for airplane authors, who wish to make their airplane engines and systems more realistic. This post links to the documents with technical details that are of interest to aircraft authors mostly. End-users are encouraged to try the Cessna 172, King Air C90 and Boeing 737 of X-Plane 11.30 to experience more fidelity in true-to-life autopilot and other system simulation.
Oxygen System
X-Plane has two separate oxygen systems, bottled/compressed O2 and chemical oxygen that can be used for both general aviation aircraft and airliners with separate crew and pax oxygen. How to set up the system for you airplane is explained here: https://developer.x-plane.com/article/the-x-plane-oxygen-system/
Besides engine-driven vacuum pumps, X-Plane can now also simulate venturi-powered vacuum systems as found on vintage aircraft and electrical backup pumps that are sometimes found in slightly better equipped general aviation aircraft. The interaction of all the pumps, manifolds and instruments is explained here: https://developer.x-plane.com/article/vacuum-systems/
Propeller-driven aircraft can have distinct behavior of the prop governors reaction to engine failure or loss of oil pressure. Depending whether your plane is a single or multi-engine, whether it is driven by piston engines or propeller turbines, and wether the turbines are of the free-rotating or single-spool design, the equipment might be drastically different. X-Plane now features negative torque sensing in addition or instead of auto-feather, overspeed governors and fuel topping governors, to make turboprop aircraft even more true-to-life: https://developer.x-plane.com/article/propeller-feathering-systems/
X-Plane now comes with a few pre-configured autopilots for airplane designers to chose from, and offers more flexibility in creating a custom one.
General Aviation Autopilots
X-Plane 11.30 adds support for single- and dual-axis rate-based autopilots, control over the trim servo, and a separate static system for an altitude pre-selector.
Airliner Autopilots
Airliner autopilots learn new auto-throttle modes, Control Wheel Steering, have two independent flight directors and up to three channels for auto land. They can optionally even have a directional servo for CAT 3 landing rollout guidance.
The documentation for tuning the autopilot constants has been clarified and expanded with new sections about the new autopilot functions in 11.30: https://developer.x-plane.com/article/x-plane-autopilot-params/
Finally, have a look at the X-Plane airliner autopilot in action, performing an auto land in a gusting cross wind:
X-Plane 11.10 brings a few changes to how airports, the airport gateway, and navdata interact.
Many pilots who try to fly realistic IFR operations with the X-Plane built-in GPS or FMS will have encountered this dreaded window already:
runway 12L not found at Vero Beach Municipal airport
The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.
Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed[citation needed], the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.
To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.
In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.
With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.
Easy runway rename in WED
WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.
Silent runway rename in X-Plane
If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.
Silent threshold fix in X-Plane
Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.
Silent and not-so-silent feedback
If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.
Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.
Any downsides?
The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.
Break ALL the scenery!
Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:
This LPV approach required the runway to be moved quite dramatically. See the taxiway that was parallel to the runway in the scenery.A closer look at the situation above. This is an extreme example. This airport scenery had the orientation of the runway badly wrong. Note where the threshold was originally placed by the author where the taxiway now ends in the grass.
These smaller features are likely to be overshadowed by the release of the G1000 for default aircraft in 11.10, so I decided to dedicate a blog post to promote the articles I’ve written – you can find them among all the guides for aircraft developers: http://developer.x-plane.com/docs/aircraft/
Electric and remote gyro systems
Back in April, I flew a Mooney M20J with a KCS55A HSI in it, and realised that it was impossible to model in X-Plane correctly, so I got to work. See the manual for an explanation of this popular HSI/remote gyro system.
I’ve written a usage guide on the new datarefs and commands that I added, along with some more detailed explanation of all the different gyro systems X-Plane simulates, in this guide for aircraft developers. I also talked about the systems at length in a Youtube live stream earlier this year.
Separate GPSS autopilot mode
This is a feature that many add-on aircraft already simulate to some degree, but by means of more or less reliable plugin trickery. The X-Plane 11 default 737 and 747 are no exception. With X-Plane 11.10, a separate GPS steering mode for the autopilot becomes a standard feature.
The new datarefs and commands are explained in detail here.
Screen-only popup instrument windows
Several people who build home-cockpit setups have asked about removing the bezels from the popup displays, so they can have only the screen of a GNS430/530, FMS or G1000 instrument to put on an external monitor, with a hardware bezel around it. While this can already be achieved through some clever hacking in the Miscellaneous.prf file, we now offer a more straightforward way to do this: The popup and pop-out windows now get their bezel graphics from the library system, so you can override the bezel graphics. How to override the bezel with nothing, if your bezel is made of hardware? Simply supply a 1×1 pixel blank .png as a bezel graphic, and X-Plane will know that you really want no bezel at all. In the case of a bezel-less 430, you’d put a 1×1 pixel png as the “cockpit/radios/GPS FMS/Garmin_430_2d.png” resource of your plane.
With X-Plane 11.02 the built-in GPS and FMS units for X-Plane 11 aircraft will also display heliports and seaplane bases. While this change is obviously needed badly for the helicopter flying community, improperly configured fixed-wing aircraft might suddenly feel themselves confronted with unsuitable options in the nearest airport selection pages and on the moving map.
Filter criteria
Every X-Plane aircraft has three parameters for airport and runway filtering that can be used to configure the moving map. These settings have existed for a long time, influenced which airports were displayed on the moving map, and kind of worked with the X-Plane 10 GPS as well. X-Plane 11 completely broke those settings for airplanes using the new X430/530 GPS, and not all aircraft authors go through the trouble of setting them up correctly.
X-Plane 11.02 correctly filters airports for GPS and FMS use as well as for the moving map based on these parameters. Because the GPS now also displays heliports and seaplane bases, it is important to set these filter parameters correctly in Plane Maker, to prevent unecessary clutter on the map.
The three settings are:
Only Airports on Map – If not checked, the GPS and moving maps will show helipads and seaports. Check when you do not want those to show up in the nearest airport list on the GPS
Only Paved Runways on Map – If not checked, the GPS and moving maps will show airports with no solid runways like grass, gravel and water surfaces
Minimum Runway Length to Show on Map – This will filter out airports where the longest runway is shorter than this distance
Note that the these settings work on a per-airport basis. That means:
At an airport with both runways and helipads, the helipads will still be shown regardless of setting.
At an airport with both paved and grass or water runways, both runways will still be shown.
In other words, airports are filtered out if they ONLY have helipads, or ONLY soft runways
For seaplanes, leave the “Only Airports” box unchecked but enter a runway length number in order to supress the heliports.
If you already set these parameters in the past and they worked in X-Plane 10, there’s nothing for you to do. If you never bothered to set them, and suddenly see places inappropriate for landing show up in your built-in GPS, that is why.
While everyone looks at the new UI in awe, X-Plane 11 also had a few important changes under the hood. With Aerosoft Navdata Pro now also supporting X-Plane 11 beta, let’s talk about one of the most boring technical features of X-Plane 11: The completely redesigned database for navigational data, which makes it much easier for data providers like Aerosoft and Navigraph to supply data updates for the X-Plane navigational facilities, while preserving scenery compatibility.
The most important goal when designing the new database was to eliminate the duplication between data in X-Plane’s world and X-Plane’s navigation systems to leave less room for subtle inconsistencies. I also wanted to address compatibility of navdata updates and global scenery (mostly concerning localizers at airports). Other improvements were the integration of SBAS path points (needed for LPV approaches) and RNP service volumes. Last but not least I wanted the ability to work with ARINC424 data directly, and eliminate most of the subtle encoding differences that result from different providers generating files with slightly different converters.
The specification of the database was finalized in September, and both Navigraph and Aerosoft were provided the tools they needed to create navdata for X-Plane 11 in the new format. Actually, we are not limited to those “big two” – as the tool is available for everyone, open-data purists can actually generate their own navdata for the US and Canada using the FAA’s file.
With the great power of the unified database comes great responsibility: The navigational data can only be as good as the world scenery it is placed in, especially the airports. Some of X-Plane’s airports in the default scenery have not kept up with the pace the real world is evolving at: runways are renamed (due to magnetic shift), extended, built or closed and X-Plane’s airport scenery is only as good as the community who cares for it. To make their life easier, we are currently working on a big automated scenery update on the server side. We will rename several thousand runways all over the world on the scenery gateway soon, and this will solve the most annoying issue people are currently facing with the new database: runways not being found because they have been renumbered.
This automatic scenery update is however only part of the solution – because we can only rename runways we have! If an airport is extended in the real world because new runways are built, we rely on the scenery gateway and its incrediblecommunity for updated airports.
I took the time to write an even more boring technical article on how everything works together in X-Plane 11: Navdata in X-Plane 11. If you are an end-user, you don’t need to bother, because here’s the TL;DR: It’s awesome. It gives you RNP approaches for airliners, and LPV approaches for GA aircraft.
Writing this article though, when I compare it to the new UI, I can’t help but feel like the poor guy in this webcomic because this is exactly how the end-user will experience the change: Most won’t even notice.
Despite many of the Lufthansa Pilots being on strike, Ben made it to Paderborn for the 13th FlightSim Conference in Germany. The event was held at the Paderborn airport, where the airport fire brigade pulled out two of their fire engines to the tarmac – the freed up hangar space was then used as the exhibition floor.
The FS Konferenz starts with a developer’s dinner, were FSX and X-Plane developers drink beer together talk about the development experience, then has a day of public exhibition, talks and interaction with users and ends in the traditional “captain’s dinner”.
We are extremely satisfied with this year’s conference. Not only were there more exhibitors and more visitors than last time, but also the impact of X-Plane is growing steadily. This became evident not so much in the public exhibition space, but in the little ad-hoc sessions we had with other developers. FSX developers who would not have touched X-Plane with a ten foot pole a few years ago were now asking us questions: How do I make a great landclass scenery? How do I make my add-on work with the X-Plane weather engine? How can I make 3d grass next to the taxiway in a way performance doesn’t suck? How do I program a gauge for X-Plane?
I think we are in for a round of new add-ons that will finally come to X-Plane.
Users with newer Ubuntu versions have reported they can’t get X-Plane to start after the update to 10.30, while it worked fine with 10.25.
Since 10.30, X-Plane links to libudev to discover devices like the Oculus Rift on Linux, and that has caused a few hiccups with some of your Linux installations out there.
No, this post is NOT about the Oculus Rift on Linux!! If you want to know the current state of Oculus Rift development, go and read this one. Though there’s a little update: At OC1, Oculus confirmed they still want to support Linux. They didn’t say when, though.
Back to libudev. X-Plane for Linux is built on a very old Linux distro, Ubuntu 10.04LTS server, which is horrendously outdated by now. But it has the advantage that binaries built on that an old version, will work with basically ANY distro out there today. Basically, the older the distro is we choose for building, the more distros users can run the binary on.
The problem with libudev0 though is, it is so old, that modern distros just don’t ship it anymore! You can only get the newer libudev1. As a work-around, you can simply sym-link libudev.so.0 to libudev.so.1 to make X-Plane find the newer version.
Starting with X-Plane 10.31, we will remove the load-time dependency on libudev again so everything is back to working like it was on 10.25.
In the future, we will load libudev dynamically based on the version the Oculus SDK requires (This is when an Oculus runtime is available for Linux, which currently isn’t).
Summary:
X-Plane 10.30: you need to create a symlink if it doesn’t work
X-Plane 10.31: no need for a symlink because we won’t depend on libudev at all
X-Plane 10.x: X-Plane will ONLY require libudev when you are using the Oculus Rift
As many of you are aware, we have been showing custom versions of X-Plane with support for the Oculus Rift at different shows and conferences. Naturally you want to get your hands on it as quickly as possible, and some of you have engaged in lively discussions on the forums and in the Steam community, which is why I’d like to give you a quick update on the current state of development.
First of all a big “thank you” to Bob from RC Simulations, who provided us with a DK2. His order was in the first batch, and he generously lent it to us until ours got delivered a few days ago.
The good news is that my DK2 now sort-of works with X-Plane on my Mac and PC. Now hold your breath, because the “sort-of” is an important part of the story. The bad news is that Oculus recently introduced some fundamental changes into the way the display of the Rift is exposed to the operating system. The changes were quite disruptive and haven’t even made it to Mac and Linux yet.
The latest SDK from Oculus comes with a proprietary display driver for Windows, to allow for a smoother display with less motion blur because it runs at 75Hz (instead of the 60Hz of virtually every computer monitor nowadays). This driver apparently works okay for Direct-X based games, but doesn’t work at all with openGL applications like X-Plane. For Mac and Linux, not even an unstable driver is available as of now.
On Windows, if we try to use the low-latency “Direct-to-Rift” mode, we get a Blue Screen of Death. It is a well-known problem of the latest Oculus SDK, that it doesn’t work with openGL. Any title with native DK2 support you find out there runs on DirectX, which also means it is a Windows-only title.
A user on the org forum posted this Star Trek quote:
“The needs of the many outweigh the needs of the few” (or “the one”).
suggesting we should’t wait for Oculus to provide Mac and Linux support and instead release a Windows beta RIGHT NOW.
In case it’s not entirely clear from I wrote above, the platform availability is not the problem! Even if we were to release Windows-only, we’d still need working openGL support in the Oculus display driver.
Using the DK2 in “Extended Desktop” mode like the DK1 is not really an option. Due to the DK2 running at 75Hz, and your primary monitor at 60Hz (unless you still have one of those heavy CRT monitors) you will get terrible vsync. It is dropping frames left and right (regardless of your actual frame rate!) causing what people on the Oculus forums refer to as “DK2 judder”. In fact, DK1 looks better than DK2 right now, given we can only use the “Extended” mode, and that is just lame.
I am heading out to Oculus Connect later this week, where I hope to get some insight into the what and when of openGL support, the roadmap for their drivers and if we are ever going to see native DK2 support on Mac and Linux.
As of now, I have to tell you that for anything but DirectX-based games, the Oculus SDK is so beta that it is not even alpha. We will have to wait for future versions of the Oculus SDK to fix those issues.
