…a new operating system.
Here’s how I think about 32 vs. 64 bit: supporting both 32 and 64 bit ABIs in X-Plane is like supporting Mac and Windows. It means a little bit more work for programmers to cover more executable types but it lets users get more out of X-Plane and add-ons on a wider variety of hardware.
We’re not switch from 32 to 64-bit. We’re adding 64-bit native execution to our list of supported configurations. (Linux nerds have been asking us for this for years! 🙂
So I view the question of “when will my add-ons support 64-bit” as similar to “when will they support a different OS.” It will come with time, but no one is dropping the existing setup.
Developers don’t have the choice to pick 32 or 64 bits; the question is whether to extend support to 64 bits.
Did any plugin developers drop Windows support when they ported their plugins to Linux? I am guessing no. And I am guessing that 64-bits will be the same way.
This is already covered in the X-Plane 64-bit FAQ, but at a minimum we will maintain 32-bit support all the way through the v10 run. My guess is 32-bits will be around for the next major version too, but we’ll figure out those system requirements when the time comes.
BTW: beta 2 is out. Mac users, you have keyboards and mice again. (The bug only happened when you start the sim in full-screen mode.) Windows users, no spinning balls. And GeForce 200 users, your shaders compile. So at a minimum most of the face-palm bugs from beta 1 are fixed.
Posted in News
by
Ben Supnik |
X-Plane 10.20 Beta 1 is now public, and it is available in both 32 and 64-bits. First, here are some things you should read:
X-Plane 10.20 Beta 1 is a somewhat raw beta. Our goal is to get 64-bit executables into the hands of as many plugin developers as possible as early as possible. There are known bugs that we haven’t held the beta for. We have not yet shipped updates to the airplanes or new art assets for autogen.
At this point, this is the info we are looking for:
- Regressions: if something works in 10.11 but does not work in 10.20, please let us know ASAP.
- 32-vs-64-bit differences: if sim functionality does not work in 64-bits but does work in 32-bits please let us know.
- Plugin authors: do report problems with your plugins.
Here are three kinds of problems we do not want to hear about:
- Long-standing bugs in the sim. First, if you have already reported a bug, you don’t need to report it again. Second, we aren’t really ready for new bugs. If you report one, that’s fine, but we’re just going to file it until a later beta.
- Problems with someone else’s plugins. We really need to hear from the plugin author. Please don’t report plugin bugs on behalf of your add-on maker.
- Plugins that aren’t 64-bit ready. We do not need any bug reports telling us that a plugin isn’t 64-bit ready. This is normal and to be expected!
Finally, for users who are very excited about 64-bit: please be patient with your add-on makers. They are only getting a complete set of 64-bit build materials today. Please give them at least 10 minutes before hounding them for 64-bit updates.
Update: beta 1 has a bug on Mac where X-Plane will ignore keyboard input if it is started in full screen. If you have a mouse, you can toggle full screen off and on to get keyboard back. We’ll fix this for beta 2 shortly.
Posted in News
by
Ben Supnik |
Follow-ups to this post:
First, the Intel Graphics. There are two sets of chips in the bucket of 4th-gen Intel motherboard graphics:
- The older half of the bucket runs Open GL 2.0 only (with GLSL version 1.10). This chipset has never run X-Plane 10. Given how insanely old and underpowered machines with this chipset tend to be, given that the driver doesn’t even support GLSL 1.20, and given how many other problems I have had with Intel GPU drivers, I am going to declare this set of chips as “unsupported”, which I think is consistent with what we have told users with this chipset over time. I believe that no one has managed to make this chipset work on Windows, which is why no recent reports have been with this chipset.
- The newer half of this chipset runs OpenGL 2.1 and apparently runs X-Plane 10.05r1. I am trying to find hardware to test this bug, and I am trying to find a contact on the driver team, so we’ll see how that goes. This isn’t going to be quick to fix, because we don’t have the hardware in house. I strongly recommend against running X-Plane on these chips, but since it used to work, I’m going to try to fix whatever has gone wrong.
Second, joysticks: as far as I can tell, 100% of users with joystick instability are using game-port joysticks and not USB. So (this is getting to be a familiar refrain) I’m going to have to go find a gameport joystick to see if I can reproduce this problem, as all of my hardware is USB.
For gameport joysticks, we may be able to get some cases to work again, but some of what I have seen is way in the bucket of “unsupported.” Here’s a hint: if, to make your gameport work, you have to take OS components from an OS you do not run and copy them into the OS you do run so that you can trick a third party driver into installing, we’re not going to support that. If it works, great, but you’re on your own.
I am not going to hold up 10.20 beta for either of these issues; since they both involve finding hardware, there will probably be some delay in getting them fixed.
Posted in News
by
Ben Supnik |
A few foolishbrave 3rd party developers are testing 64-bit X-Plane builds, as well as our internal art team. Their early testing will help us fix a few of the “duh” bugs quickly before we go public beta, which should be Real Soon Now.™
(Please do not ask for a 64-bit build; we selected the first-round testers and we are not looking for any more private testers. Everyone will get the build soon!)
Posted in News
by
Ben Supnik |
I’m trying to migrate our developer documentation from the Wiki to this site. See the menu up top for articles, file formats, and tools.
One document I just posted here: A Checklist for Updating Aircraft to X-Plane 10. If you are working on airplane conversion, I strongly recommend looking over the various items. A lot are “check that X isn’t hosed” – there are very few mandatory changes.
Some of our users have the bad luck of having a laptop with Intel 4th generation graphics. This is the last generation of the “GMA” graphics cores – they generally come on motherboard (and often you’ll have one that you don’t use even if you have a PCIe graphics card) and they’re not very powerful. Motherboard graphics are designed to lower the cost of the entire computer for users who don’t need 3-d. They are not designed to make X-Plane look awesome.
These GPUs are causing two problems with X-Plane 10.10:
- They crash on startup when we ask the driver about our window’s format. Why it does that is not yet clear to me, but there may be a work-around.
- Our shaders won’t run on the GPU, which claims we ran out of texture units.
I consider this second problem very silly, as the card tells us how many texture units it has, the number is the same as every other GPU, and we don’t use more than those numbers. There may not be a work-around to the second problem; in particular if the shader compiler has a bug that causes it to misunderstand our shaders, we won’t be able to do anything.
So at this point X-Plane compatibility with the gen-4 Intel GPUs is an unknown. It looks like there are subtle core differences within the series that may also cause problems.
I can tell you this: if we ever get them running, it’s not going to be pretty or fast. I have the 6th generation GPUs (Intel HD graphics in an i5-2500) and the performance is not on the same planet as a discrete GPU.
Other Intel Cores
We do not support the 3rd generation and earlier GMA GPUs. The numbering scheme is really nutty, so that table can help.
We do support “Intel HD” graphics – they’re not great, but they do run. That includes any built-in mobo GPU from a “core i5” or “core i7” chip.
TL;DR
The short version is: if you have a gen-4 Intel GPU and see crashing, please stand by; we are investigating now. We will either fix the crash and provide a work-around in the upcoming 10.20 patch or declare the GPU unusable. I’ll post an update in a few days.
Posted in News
by
Ben Supnik |
This post follows up on the case for DDS and DDS in v10 and answers some basic questions.
DDS and Texture Compression are Not the Same!
This is the first and most important point: the decision to compress textures and the decision to use DDS are not the same!
Texture compression is decided by the user. If the user clicks “compress textures” (and nearly all users should do this) then 99% of the textures in your add-onwill be compressed. You can’t avoid this. The user has spoken and said “sorry, I don’t have 3 GB of VRAM, we need to tighten things up.”
DDS is a pre-compressed format; DDS says “well, if you are going to compress, I have already done the compression for you with DDSTool, so it will look better. See the pictures in the posts above for why this is so important!
I cannot emphasize this enough: most users are going to have to use compression to save VRAM, so you should ship DDS files so that the compressed images look good. You can ship DDS and PNG if you want to ensure that the uncompressed case looks good too, but I think that users running uncompressed is going to be rare.
Does DDS Improve Framerate?
No! See the above post: the user may be running compressed textures regardless of whether you ship a DDS, so when you ship a DDS you may see no VRAM savings and no FPS change. All you will get are compressed textures that look better.
Does Compression Improve Framerate?
Sometimes. Texture compression will improve framerate under two conditions:
- The texture unit bandwidth on the GPU is exhausted. This is very rare now – I haven’t seen this happen since the Radeon 9600 XT.
- The user is out of VRAM. This is quite common.
But recall how free VRAM affects framerate:
- When the user runs out of VRAM, the fps loss is often catastrophic. The user might see huge jerking, big pauses in framerate especially as the camera moves, and performance will be unusable.
- When the user has extra unused VRAM, there is no benefit – framerate does not go up indefinitely by freeing up VRAM.
So most users will simply turn down texture resolution until they can fly. Thus the real effect of texture compression is to let users turn their overall texture resolution back up again one notch, improving the overall look of the sim.
Is There Any Way to Make DDS Look Less Bad?
Sometimes DDS is relatively harmless to a texture, and sometimes it just absolutely destroys it. I don’t have a good answer to this, except: be sure to run the latest DDSTool/XGrinder (see the “command line tools” option on this site) when targeting X-Plane 10, and never set your gamma to anything other than 2.2. I do hope to someday look at improving DDS grinding capabilities.
X-Plane 10.11 is now final, so you will receive an update notification even if you have not participated in the beta program.
Starting with 10.11, I am stripping the ‘r’ designation off the end of the build; the complete build number is still visible in the log file and properties, but what you see on your startup screen will just read 10.11.
I do not know if we will cut an X-Plane 10.12 before we get into a 10.20 public beta of 64-bit; I have seen a number of bug reports for 10.10/10.11 that need investigation, but I don’t know if the problems are due to bugs, running out of memory, rendering settings cranked too high, etc.
The main goal of 10.20 is to get us to 64 bit; we’ll also ship better anti-aliasing and autogen in that build. We aren’t sure what will come in 10.30, but at this point more performance tuning and stabilization is likely.
A while ago, I wrote up a summary of the issues with OSM and water. I still do not know a time-frame or plan for OSM recutting, but I can say it will be after getting 64-bit done, and once 64-bit is done, it will be high priority. If the water you care about is not in the OSM map itself, a recut won’t help until you or someone else in the OSM community updates the map.
(For Americans who are frustrated about water that was in X-Plane 9 but is not in X-Plane 10: X-Plane 9 used US Government data. There is work in the US mapping community to get the NHD data into OSM; I suggest participating in this effort. You can import and check a single water shed and thus bring a local region up to date, and the changes are ‘forever’ since they are in the OSM data set themselves.)
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.
X-Plane 10.11 rc3 is ready for testing. If you see a lot of spurious warnings about LOD errors in your Log.txt file on Windows, get this build by running the updater and checking “get betas” – it should help.
Posted in News
by
Ben Supnik |
