In my previous post, I posted a screenshot of X-Plane 10.50 with the new autogen update we are working on. This is an AG update that includes a bunch of buildings, particularly tall ones; I’ll post a lot more detail no that in a separate post.
One of the main questions in the blog comments was: “how are you getting this pic with 30 fps? Did you get new hardware?”
Well, I did get new hardware; a few months ago I finally swapped in the first-gen 5K iMac with the R295X GPU or whatever it is. (I thought this was latest but I see now Apple has revised the machine and bumped the GPU up a generation.) So that’s a machine with a bit more kick than my older 2008 Mac Pro.
But more importantly: X-Plane’s autogen engine is really fast. It hits the instancing path almost all of the time and as a result it can draw a lot of autogen at reasonable fps.
When X-Plane 10.0 shipped, I could run the autogen + roads maxed out my old Sandy Bridge PC – that was before optimization on hardware five years ago. I think this is one of the things that X-Plane 10 does really well that people tend not to notice; that code path was hot from day 1!
There’s a third thing going on here: I picked my rendering settings to promote AG + framerate; you can do that too. I see a lot of users running with relatively low autogen density and poor fps due to other settings. And clearly people like lots of buildings.
So here are some tips on how to get a lot of autogen and decent framerate.
- Make sure you haven’t overloaded VRAM. As long as everything that needs to be in VRAM, you’re done; there’s no “better”- you just need to not be overloaded. The way to do this is to turn texture res way down, tune up the system, and then at the end increase texture res until framerate suffers; then turn it down one notch. Remember to restart each time to get accurate texture use.
- Start with the GPU underloaded – small window, no clouds, low FSAA. You can turn those up later after you get the CPU utilized. (If the GPU is bogged down you can’t even see what you are doing.) Note that when you do go to crank GPU settings, do this first and crank texture res last, as the high GPU settings burn “extra” VRAM for off-screen buffers.
- Turn down settings that chew up CPU. Considering turning off AI aircraft and turn the cars way way down. If you use a payware aircraft that eats CPU (and many of them do) you may want to keep it so you can see what your “real” performance will be; saving 10 fps by throwing out the aircraft isn’t great if you want to actually fly.
- Turn down settings that amplify the cost of AG. This might be the most important one; in those pics, shadows are in “overlay” and water reflections are way down. When those settings go up, every autogen building is drawn for shadows and reflections, not just in the scene, making the AG many times more expensive. I suggest shadows on the aircraft in 3-d and the second lowest reflection setting.
You Can’t Always Get What You Want
The other day I was forwarded a very (cough) angry customer email; the customer had a gamer-class PC, turned everything in X-Plane up to max, got about 5 fps, and went absolutely ballistic. We see emails like this over and over and over and over again. “How much @#$@# money do I have to spend to turn everything up?”
In the long term, our plan is to change the rendering settings so a high-end gamer-class PC can run with every single slider topped out; if you want some of the super high settings in some areas of the sim by turning down other areas, this will be possible only by hacking the config files, not by the UI. The current rendering settings scheme is simply not friendly to users.
With that in mind, I look at what combinations of settings we can max out in hardware (to the point where the artists intended things to be) and still have good fps. My current view is:
- The AG system itself is there – you can have all of the AG, and assuming you don’t run out of VRAM, the artists aren’t going to create “more dense” AG, just more variety.
- AG + shadows is still not there, and this my next goal for optimization. My intention is to make shadows fast enough that a gamer class PC can run max shadows and max autogen at 30 fps. We’re no there, but I believe this is possible, and I believe that it is possible using OpenGL.*
- The cars are also not there – they’re just too big of a penalty. I certainly think we could get 2x to 3x the car density for the performance cost that the low setting cars have – and that would be a good place to be.
* Computers also just get faster over time, so I suppose I could solve this by taking a ten year sabbatical. 🙂 Seriously though, if the cars would run at playable fps at medium res, I’d be okay to let hardware improvements get us to really dense traffic.
Update: some answers about performance, hardware and settings.
A user asked me to write a little bit about Vulkan. My first reaction was to not post anything for a simple reason: Vulkan is a feature for me, not for you. That is, Vulkan does not make you (the user of X-Plane’s) life directly better; instead it makes my development job easier and it makes it possible for me to create a better X-Plane.
Some day if we end up running on multiple drivers (e.g. Vulkan and OpenGL and Metal), you may not be able to tell the difference between the Vulkan and OpenGL version; the sky won’t be more blue, the clouds won’t be more puffy. I can’t think of any features exposed by Vulkan that aren’t in OpenGL 4.x with extensions now — we already have sparse memory, tessellation and compute in OpenGL. (But then, you might actually be able to tell because framerate might be higher.)
Anyway, having finished reading the (700+ page – that’s what down time in the airport is for) Vulkan spec last week, the rest of this post is my view on Vulkan as a 3-d graphics developer. This is definitely an “inside baseball” kind of post, so if you want to go surf cat videos, I won’t be offended!
The Problems with OpenGL
For an application like X-Plane, Vulkan is an improvement over OpenGL; to understand why we have to look at the problems with OpenGL as an API that allows applications to communicate with 3-d hardware drivers. There are a few:
- OpenGL’s approach to multi-core and threading are antithetical to performance. This is really the straw that broke the camels back for me and OpenGL. Developers who know me know that I’m not a “burn it down and start from scratch” kind of guy*. But the threading model in OpenGL requires drivers to hurt performance with safety checks and locks that an application can’t get away from. This isn’t something you can just fix with an extension.
- OpenGL’s object and binding model also make multicore performance difficult. The use of a “current” object in a context and the ability to radically change objects after they are built mean lots of driver paths require internal locks.
- OpenGL’s compatibility is its greatest strength and greatest weakness. The original plan to rebuild the object model in OpenGL 3.0 died before it was released. Instead the ARB came up with a plan to optionally deprecate APIs. Every vendor of OpenGL except for Apple has chosen to keep backward compatibility with everything. That’s great for keeping old apps working, but it means every change to OpenGL is expected to work with everything else there ever was, ever.
- OpenGL requires that shaders be compiled by the driver. This means an application is exposed to idiosyncrasies in the compiler of each driver we ship with. This isn’t as bad as it used to be, but writing shaders is still a matter of write-once, check everywhere.**
How Vulkan Helps: The design principles behind the Vulkan API address all of these issues.
- The biggest single feature of Vulkan is its new multi-core friendly threading model. Vulkan is “externally” synchronized, which basically means applications can do whatever they want, but have to talk to different parts of the driver from different threads. To use an analogy: OpenGL is filled with traffic lights. Vulkan doesn’t even have stop signs, and it’s up to two drivers to not be on the same road at the same time. (As application developers, this is a great setup, as we know what roads we are on and can plan to not have collisions.)
- The object model clearly separates expensive creation operations from inexpensive usage operations. Expensive object creation can be done on worker threads or at initialization time. Objects can’t be radically reconfigured once they are built, so the small changes that are allowed to existing objects aren’t slow.
- Shaders are compiled ahead of time into an intermediate representation; no more shader compile fails after a driver update.
Vulkan is a smaller, lower level API with clear performance guidelines and a focus on multicore from day one. This is a good fit for what we need with X-Plane.
The Problems with the OpenGL Ecosystem
The OpenGL ecosystem is the collection of all of the companies and programmers working with OpenGL. This includes the vendors of graphics chips who create OpenGL drivers (NVidia, AMD, Intel, Imagination, Qualcomm, ARM), OS vendors who provide OpenGL interfaces (Apple and Google), the major game engine developers that have the ear of the hardware vendors (think Unreal Engine 4, Unity, etc.), the major CAD application developers, etc.
More serious for OpenGL than the problems of the API is the state of the ecosystem.
- OpenGL’s API is underspecified: there is no comprehensive conformance test for OpenGL, so we can’t really know if an OpenGL driver works or is buggy.
- OpenGL’s API is underspecified: no performance guarantees or even recommendations are made. If you ever look at the tech blog Chris and I maintain, it’s full of posts about the latest witchcraft I’ve found to make vertex throughput go faster. That stuff isn’t part of the GL spec, yet you have to know it to build a real-time graphics application.
Given the lack of specifics, application developers and driver writers end up locked in a sort of death-spiral:
- Driver writers observe the behavior of applications and change the driver behavior to work around applications. This can include trying to improve performance and trying to bandage around broken behavior. (Since games are the typical benchmark for new graphics cards, NVidia and AMD are hugely incentivized to make games run faster by any means possible.)
- App developers observe the behavior of the drivers and change application behavior to work around driver issues. In X-Plane’s case this often means intentionally not using the optimal code path for driver stack X because it is slow. If the driver team ever fixes code path X, X-Plane still isn’t using it; when the driver team looks at performance they then decide to improve code path Y (that we are using, the backup plan) because that is what will make our app benchmark faster.
How Vulkan Helps: Vulkan helps by being much more highly specified in terms of both conformance and performance.
- Vulkan is a much smaller, simpler API – OpenGL has simply become too complicated to completely test. With Vulkan, we can hope to test the entire driver.
- Vulkan is being built with an open source test suite from day 1, with the goal being to build up a huge number of tests so we can know that a given driver is correct.
- The Vulkan API is very clear about what operations are fast and what operations are slow. An application that uses the fast API can expect fast performance on those code paths. Guessing is not required.
Downsides to Vulkan
For smaller OpenGL application developers like Laminar Research, I can think of just one down-side; it’s one that I haven’t seen a lot of application developers talk about, probably because it requires admitting that we (the app developers) might not be as smart as those driver guys.
OpenGL is a higher level API; OpenGL applications leave some of the hard problems of 3-d graphics up to the driver. This means that some of these very hard, very important performance problems are being solved by a team of engineers from the company that built the hardware. They have resources, they know everything about the particular hardware they are coding for, and performance is job one.
Vulkan is a low level API; with Vulkan, some of those hard problems will be solved by Chris.
Ha ha…no, I’m totally kidding. We don’t let Chris play with pointers or any other sharp objects. That code will be written by me, and it’s a safe bet that I know less about the hardware than the driver team and have less time to do pure performance work then all of the engineers at Nvidia or AMD who work on the OpenGL stack.
This is a calculated risk for Vulkan as an eco-system. The hope is that (1) with specific information about performance as part of an API, us application developers won’t screw things up too badly and (2) because we (the application developers) know more about our specific applications, we can optimize performance in ways the driver guys can’t because they don’t have the bigger picture. One of the hardest problems in a graphics API is conveying intent; OpenGL drivers spend a ton of code trying to guess what the application is trying to do. Vulkan solves this problem by letting the application make performance decisions itself.
Next Steps
If you know OpenGL but don’t know a lot about how 3-d graphics hardware really works, reading the Vulkan spec is a little bit like believing that Santa Claus brings your presents down the chimney and then [spoiler alert] one day reading a 700+ page PDF that explains how your parents actually buy the presents a month or two in advance, wrap and hide them, and then sneak them under the tree while you are asleep.
For X-Plane, the Vulkan spec makes clear what types of operations future drivers will support, what will be done for us, and what we have to do ourselves. This gives us a good framework to then incrementally build next-generation rendering code in X-Plane that is “Vulkan-friendly” – even if it is still using OpenGL. My guess is that this new code will be faster than the code it replaces even before we change drivers.
Once we have the rendering code restructured and modernized, we can then set it up to run on Vulkan or OpenGL, taking advantage of the Vulkan pathways where they exist.
One final thought: I have no idea how the actual experience of coding for Vulkan will be. It may be that everything “just works”, or it may be an exercise in frustration. Once we’ve been through a full port I’ll post a post-mortem, but I think it’s too soon for anyone out there to have good realistic feedback on a full Vulkan porting experience from OpenGL.***
* And when people suggest ground up rewrites I usually link to this.
** For what it’s worth, the driver shader bugs I see (and the ones that really take up my time) are bugs in the back end of the compiler, where optimized machine code for the GPU are generated. Vulkan isn’t going to fix this; Vulkan removes the front end of the compiler from the driver but not the back end.
*** Yes, there are games running on Vulkan now. But if your game is already running on multiple APIs, that’s different from porting a straight OpenGL app. The final spec and roduction drivers haven’t been out long enough for anyone to be able to say “I ported half a million lines of OpenGL code to Vulkan and here’s the result.”
Ondrej has posted a public thread about the new version of the Blender 2.7 exporter here.
The 3.3 release is the first release where we (Laminar Research) have worked closely with Ondrej to build what we hope will be one of the future cornerstones of modeling for X-Plane.
If you are currently using Blender 2.49 or AC3D, I expect that 2.73 will provide the best way forward for modeling in X-Plane.
New Stuff
The new release has a few major features, all aiming to create a new modern work-flow:
- All animation bugs are fixed. (At least,we think – if you find one, please report it ASAP!) This means animation is WYSIWYG. Armatures are supported for animation as well as animated data block containers.
- The exporter understands all modern OBJ features, including ones scheduled for release in X-Plane 10.50.
- Instancing is handled via a single option with exporter validation, so you don’t have to know how instancing works to get instancing.
- The material rules are validated, and materials are found automatically; you can simply model as you want and Blender will do its best to export it or tell you if there is a problem.
- Specular and Normal maps are ‘merged’ together from two separate sources. This lets you set specularity and normal maps in separate material channels in Blender for a more WYSIWYG approach. It also means no more messing with Photoshop to combine these layers.
The goal of many of these is to hide the idiosyncrasies of X-Plane’s modeling format and provide a cleaner, more artist-friendly view of modeling.
Regarding instancing: the model we have adopted is the one we used internally on the 2.49 exporter: you (the artist) tag an export as either “instanced” or not.
- If instancing is on, the exporter writes only data to the OBJ that will be hardware-instanced by X-Plane. If you do something that cannot be instanced, like animation, you get an export error telling you what you have to remove.
- If instancing is off, the exporter writes the object normally.
The win here is that you don’t have to know the (complicated) instancing rules; set instancing for the scenery objects you need to make fast in bulk (e.g. a luggage cart, a house, something that will be used many times in a small area) and you’ll get optimal output.
Optimization – Coming Soon
The goal of the 3.3 release was to set up an environment where authors could work using the new work flow. We have not finished optimizing the OBJ output.
If you are using the existing 2.7 exporter for airplane work, the output should be similar in performance. If you are using the 2.49 exporter, the new output is (like the current 2.7 exporter) not as well optimized.
In a future update, we will tighten up the generated OBJ code; this should not affect anyone other than producing better OBJs.
Compatibility
The new exporter should be fully work-flow compatible with the previous Blender 2.7 exporter; if you find your existing project does not work, please file a bug!
Our plan is to create a migration tool for Blender 2.49 projects; this will forward-convert the datarefs on annotations, manipulators, and object properties from 2.49 to 2.73 format. This lets authors using 2.49 move forward to 2.73 and have a migration path for existing content. (This work is not started yet, but is planned – we have our own aircraft we need to keep working on.)
Things have been quiet with the mobile product recently but that’s only because we have been working on some new features that we didn’t want to talk about until we had them running reasonably well on a variety of devices. Well, we have made some great progress and now I’m happy to start talking about it.
What’s the big secret?
So what have we been working on…..? Taking the entire X-Plane 10 Desktop flight model and aircraft systems! That means all of the physics, all of the systems, all of the datarefs, as well as 99.9% of the panel system and instruments*. I cannot emphasize enough how unprecedented this is on a mobile device…and it will be free of course. Read on for specifics…
Flight Model History
Let’s rewind time back to 2007 when the original iPhone was being released. We had about 25MB of memory to work with and a very limited processor. There was absolutely no choice but to prune the flight physics and all of the systems back to the bare minimum. This has been our mobile product’s foundation for the past 9 years…a reasonably good approximation of flight physics and systems that is adequate for mobile devices…but very limiting for us as developers and also a bit limiting for users as well. Lately, we’ve been moving over pieces of the desktop flight model a little bit at a time (for example, Airliners required a better slat and flap system) but it’s time consuming and tedious.
Where we’re headed…
Over the last couple of months we’ve been reorganizing our systems and now have most of the desktop systems running on our mobile product…even on the older devices that we support like the original iPad Mini/iPad 2/iPhone 4s. We’re still actively integrating the systems so it’s not ready for release just yet, but a lot of the work is done.
So what does this mean for users? Archimedes said “Give me a lever and a place to stand and I will move the earth.” The mobile product sharing the flight model and systems with desktop is a HUGE….MASSIVE….LEVER. It means that mobile instantly gets an FAA Approved flight model…the same one that real pilots train on. An instantly improved autopilot, no more bounced landings (unless you fly like Ben…in which case you’ll still bounce ;)) full electrical, hydraulic, engine, prop, fuel, radios, navigation, pressurization, starter, trim and gear systems.
With all of those systems available in their entirety, it means that the beautiful 3D cockpits that our artists have been developing can come to life with interactivity to touch and manipulate all of the same systems that you can on desktop. Start/Shutdown the aircraft the right way, tune all of the radios, operate the full autopilot etc.
This is the symbiotic relationship that we’ve been talking about since the launch of V10 Mobile. Mobile feature development will improve the Desktop product, and Desktop features will trickle down into the Mobile product.
When is this happening?
Soon? I expect much of this to be done and the first update to happen by the spring for iOS and Android. It will not be done in one release but over several.
The release schedule and contents are still not completely concrete at this point but if I were to take a guess, I’d say that the first release will include the complete flight model. This will be an incremental update for end users because while the flight dynamics will change, the interaction will not change much. It will have the same simple 3 button autopilot and minimal interactivity with the 3D cockpit.
The second and subsequent releases will start to expose much of this new system to users. I would expect to see a new 2D autopilot UI that exposes the complexity of the desktop autopilot…heading, altitude, speed, LNAV, VNAV etc. I would also expect that some of the aircraft panels will have been updated with manipulators that allow you to start touching all kinds of buttons and knobs.
With this kind of leverage, we can release new features faster than ever before. I’ll have more details on that specifically when the time is appropriate.
*We will not have a working 430/530 on mobile in the short term nor will we have a few very uncommon and extreme instruments.
Yesterday we had a bit of a digital download fire-drill: over a dozen Mac users filed bugs or contacted tech support to say that X-Plane couldn’t get their machine ID.
When X-Plane’s copy protection doesn’t work, that becomes the top thing on the priority list, full stop; we never want to see a paying customer unable to use X-Plane.
I contacted a number of users to request detailed information, and from those who I have heard back from, the answer has been consistent: the problem mysteriously vanished just as quickly as it appeared. Some of the users reported making the problem go away by reinstalling or rebooting, but each “work-around” was different, and some users made no changes, making me think the problem fixed itself.
So…the whole thing is a total mystery. While I’m happy to see users flying again as quickly as possible, not knowing what went wrong is disconcerting.
If you are on a Mac and you still can’t use your product key, please do contact tech support by email!
Update: turns out there’s a real explanation – see the comments section. I’m at least relieved that our code didn’t mysteriously go AWOL for one day.
X-Plane 10.45 has been released; if you have run X-Plane you already know that.
This release has another big update to the global airports and updated navigation data. Here’s a complete list of everything changed.
One new feature of 10.45 that may change how you use X-Plane: the global airports no longer conflict with custom scenery – even if you have custom scenery that doesn’t have proper exclusion zones.
So if you have been disabling the global airports due to conflicts, you don’t need to do this anymore. You can use your custom scenery and keep the global airports around.
We are already well into X-Plane 10.50 development – we’ve actually been doing significant 10.50 work for a while now. I’ll have more posts on that soon – right now we are aiming to have 10.50 in public beta in a few weeks.*
* That’s a vague time estimate because it’s not super accurate. Feature work is not complete for 10.50, so it’s hard to know when it will really be done. Our goal isn’t to get 10.50 into beta at a certain date; it is to make X-Plane better as efficiently as possible.
Posted in News
by
Ben Supnik |
I’m going to keep going with “random stuff I looked at today” and see if there’s something for authors mixed in.
I spent part of today measuring shader and texture changes in our engine under heavy load – my goal was to get a sense of how much data we’d be pushing through a next-gen API (e.g. Vulkan, Metal, DX12) if we just did a straight port of the engine. This was just a fact finding mission.
The only problem was: the numbers were just absolutely awful. Terrible. Unusable!
Then I noticed the other thing: the entire area of KSEA was littered with thousands of Fed-Ex trucks. Just tons and tons of them! Only Fed-Ex trucks on the road, and only Fed-Ex trucks parked on the street.
Wha?
Leftovers For Lunch
The Fed-Ex trucks were a left-over. I do this to myself all the time: I create a dumb custom scenery pack to test some part of the sim and then forget to remove it from my working X-Plane folder.
Before X-Plane 1040 there was a bug where cars and trucks on the road could crash the sim if you viewed them across a DSF tile boundary and the 3-d models were not instanced. This last point is why the bug went unfixed for so long; the car set we ship with is entirely instanced for performance.
So I built a library with a Fed-Ex truck that was intentionally not instanced to reproduce the bug and forgot about it. The custom scenery pack was why my traffic looked silly, and the non-instanced traffic was why my stats showed the rendering engine doing 4x more on the CPU work than it was supposed to.
(Since X-Plane was in debug mode, the framerate was expected to be terrible due to unoptimized code and debug checks running on an old laptop with the scenery cranked to the max.)
So there’s a take-away here and it is:
OBJs in a Custom Vehicle Pack Should Be Instancing-Friendly
There are a few custom vehicle packs for X-Plane floating around the web, and the quality of the objects with regards to performance is mixed and overall not very good – probably some of these packs pre-date X-Plane 10.
Instancing is the ability for X-Plane to draw more than one OBJ in a single instruction to the GPU. We implement instancing by observing your OBJ as we load it and noting whether the OBJ contains anything complicated (dataref usage, animation, lots of material changes) or if it is more or less just a big pile of triangles.
If we have the latter case, then we mark the object as instancing friendly, and when it is drawn, all objects of that type are collected and drawn at once. The instancing code path in X-Plane is thus separate and much faster for both X-Plane itself and the driver.
Since you can have a lot of the same car on the roads, even with a varied collection, it’s worth it to be instanced!
How to Tell If Your Object Is Instance-Friendly
To see if your object is instancing friendly:
- Make a custom scenery pack and place ten of the objects very close to each other (e.g. at an airport).
- Load the airport in X-Plane and in DRE set the art control “terrain/kill_clusters” to 1.
When you do this, all of the instanced objects that come from DSFs will disappear, and all of the non-instanced ones will remain.
Your object will be instance-friendly if:
- It uses no animations
- It uses no ATTRibutes mid-object – use the new GLOBAL properties instead
- For cars, LOD is okay (but non-additive LOD will make the WED test fail). For cars you should only use one LOD anyway.
- Only some named lights are instancing friendly; fortunately the headlight/taillight ones are.
Draped geometry is instancing-friendly, but don’t use it for vehicles.
In the new Blender 2.7 exporter (and our branch of the Blender 2.49 exporter) instancing is made quite easy: you mark an object as “instanced” and one of two things will happen:
- Blender will write only stuff that is instancing friendly or
- The export will fail with an error telling you what you did wrong.
Thus when you -need- something to be instanced (scenery objects, etc.) you just tell the exporter to enforce it.
Here are some things where instancing really matters:
- Repeated buildings in autogen.
- Static aircraft that repeat a lot.
- “Clutter” on the ramp (baggage trucks, etc.).
- 3-d modeled vegetation that gets repeated.
- Cars (both parked and moving)
Here are some cases where it does not matter:
- Aircraft-attached objects. Since aircraft attached objects aren’t usually repeated and almost always have a lot of complicated stuff, instancing doesn’t matter or work here. Instancing is really for scenery.
- Single extremely complicated objects like the Nimitz.
Right now objects drawn with the XPLMDrawObjects API call do not benefit from instancing, but this is probably something that will change in the future, as long as every “instance” is fed through a single XPLMDrawObjects call.
First, X-Plane 10.45 release candidate 2 is out. There was a bug in RC1 where the instructor’s operator station (IOS) couldn’t change aircraft over the network. I’m hoping we don’t have any other last-minute fire-drills; the IOS bug was reported the day I was going to call RC1 final.
I keep on telling myself during the day “I’ll blog some developer news later when I’m too tired to code” and (shockingly) at 10 pm, after the second round of coding after the kids have gone to bed, I find myself too tired and go “meh, I’ll blog tomorrow.”
So in an attempt to post something rather than keep delaying…
Spock And Friends
The Vulkan API was released today. Vulkan is the third new next generation 3-d graphics API (the other two are Metal for OS X and iOS and DirectX 12 for Windows). Vulkan should be available on Windows, Linux and Android devices. The specification is 651 pages long, so I have some light reading to do.
Faster Cockpit Lights
FlightFactor sent me a test case to look at a while ago – a possible bug in the Blender 2.49 exporter. While exploring the performance of the test case, I discovered that the code that runs ATTR_lit_level in a cockpit OBJ was a lot less performant. (If you don’t create 3-d cockpits, ATTR_lit_level lets you turn the brightness of a 3-d model’s night texture up and down based on a dataref; it is crucial for creating cockpit lighting animations, including annunciators.)
I ripped out a pretty huge pile of code in the process, and I am hoping we’ll see a performance boost. On the mobile product (this code is shared on mobile and desktop) the changes cut the number of driver calls we make down by about 25%. (That doesn’t mean a 25% speed-up – not all calls are equal, but it shows that there was a real win in there.) My measurements of the ATTR_lit_level test case run the OBJ itself 10x faster. (Again, that doesn’t mean 10x the framerate – it means this one very small part of X-Plane runs 10x faster). Once the work is done I’ll post some performance numbers. This code is targeted at X-Plane 10.50.
Posted in News
by
Ben Supnik |
X-Plane 10.45 release candidate 1 is out (and will be available on Steam for users who have selected to get betas within a few days). If you aren’t running betas and would like to try it, run your X-Plane Installer, pick update and check “Get Betas”.
If you are the developer of an add-on aircraft and you haven’t tried 10.45 yet, please try it as soon as possible! We caught a few surprising systems-related bugs and fixed them for RC1, but overall beta bug reporting has been quite low; we can’t fix what we don’t know about, and some bugs might only be reproducible using your add-on.
X-Plane 10.45 is a “small” patch for us in that it doesn’t contain major changes to the code, but it contains a number of features you might like:
- An update to the global airports.
- The global airports won’t conflict with custom scenery – new exclusion technology prevents overlapping buildings.
- Nav data has been significantly updated – lots of bug fixes are in 10.45.
- The GPS data for the G430 now contains IAFs, so you can fly GPS approaches with proper transitions.
- Proper prop torque for aircraft that opt in.
I keep meaning to post about other stuff we’re working on; I’ll post an update soon. But for now, try 10.45 before it goes out the door!
