Sometimes I have one of those weeks where all I do is look at crashes and weird behavior. This is turning into one of those weeks. So here’s some status on the various bugs floating around.
I should say: you’ll find a lot of developers blaming the technology providers for bugs (just look at how many OpenGL developers have blamed ATI for their apps crashing). Sometimes it’s the app, sometimes it’s the driver. More importantly:
- You don’t know who’s fault it is until you fully understand the bug.
- The fix for a bug might not be in the broken code. That is, one piece of code can work around a bug in another.
So…you can’t necessarily tell whose fault it was from new drivers coming out, us changing the sim, etc. But…when it’s my stupid code, I’ll admit it openly – no one should think that a bunch of other smart programmers are screwing up on my behalf. (This is also useful to other apps developers, who can know that my bug isn’t the same as their bug, since my bug was in my code.)
X-Plane: we’re happy with 921r2 finally…the final bug (crash on startup on the Mac) was due to an incompatibility between Apple’s OpenAL implementation and special memory allocator (which is really just a wrapper around NEDMalloc). I still don’t know exactly what the rules should be (you try reading the C++ spec!) but for now we turned the allocator off on Mac.
(This brings up another issue about bugs – you can’t tell whose bug it is by whose code crashes, since one piece of code can sabotage another.)
So the next X-Plane release will probably be 930, with new features. We may have a few more language patches if needed.
iPhone: the 9.01 iPhone patch is out, and it improves framerate a bit. We are still seeing crashes on startup for users who have just downloaded the app. Rebooting the phone will fix this, but please see
this post for more info! We need your help to collect more data.
Radeon 9800 on Windows: for the longest time we’ve had users reporting “framebuffer incomplete” errors when using catalyst 8.x drivers, an R300 chipset, and Windows with X-Plane 9.x. I have been trying to reproduce this problem “in the lab” off and on for months, but finally saw it this week. From what I can tell, we’re getting into some low-memory condition and the driver is freaking out in various ways. The command line options people sometimes use to get past this are probably rearranging memory, not saving it. I don’t know why the Catalyst 7.x drivers don’t have this problem. But…at least I am making more progress than I was before. Please see
this post for more info.
Installers: I am working on the 2.05 installer. I have seen a number of users report problems running a full install from DVDs, so I am just starting to investigate that. I will post more when I have something to test. Unfortunately the problems reported are not something we see here.
The 921 patch is now available. This fixes the bad-alloc problems relating to complex airports.
Please note: if you have a bad-alloc crash, it could be because you are out of memory. Make sure you have virtual memory turned on, your page file is large enough, your disk isn’t full, etc. If you have a bad alloc error, try the sim without third party add-ons to see if you really are running out of memory. If you are running Vista or XP, use /3GB or the BCD – see this for more info. Basically when you are running out of memory, you either can crash on “bad alloc” if we need memory for the CPU or “we ran out of video card memory” if we can’t map geometry into virtual memory.
If you get a crash with 921 on OS X, please let me know by email! I’ve seen one of these reports.
I also have cuts of the new installer/updater suite, version 2.05 – if you are going to update, tryo ne of these:
http://dev.x-plane.com/update/installers9/stage/
The main features of the new installer are:
- Support for French, Spanish, Italian, German, and Russian.
- Clearer colors on the world map.
- Scanning the global scenery folder to add/remove scenery is much faster.
I recommedn the new installers for that last point alone.
There are a lot of patches coming out soon:
- 921rc1 – this is a patch on 920 to fix the bad-alloc crash.
- 921rc2 – same as 921rc1, but with some improvements to the translations.
Why two patches in a row? Basically we did 921 rc1 a while ago, but Austin’s net connection got hit by lightning. He’s on a, um, “borrowed” wifi signal right now, and it isn’t real strong, so the 921 patch is just taking forever to post. It’s equally likely that we skip straight to 921 rc2 because we can get the translation improvements done before we even get the patch up on the server.
Now regarding French: first I must say thank you to Daniel, who is helping us with the translation…we’ve been behind schedule, and his helping us with a big block of strings is a real life saver. I must also thank my wife, who was also up pretty late working on some strings. 921 rc2 will address all other languages; we’ll do a new patch once we have complete a French translation. If this is soon, that could be 922 (another patch). If it takes a while, it’ll be part of 930 (which will have new features). Time will tell!
There is also an update coming out for the iphone soon – improvements to the UI and some framerate improvements. I believe that the iTunes store should make downloading the update pretty seamless.
After all this patching, we’re on to 930. I’m not entirely sure what will be in 930 yet, but I have already made some rendering engine changes for 930 that improve framerate.
EDIT: 921r1 is now up as a beta – so you can get it if you set your installer to “get betas”. If you have the bad_alloc crash, try this beta.
Posted in News
by
Ben Supnik |
Traditionally, a pilot’s priorities are: aviate, navigate, communicate.
But that might not be true for X-Plane for the iPhone.
It’s real! And it pretty much is X-Plane – there really are OBJs and DSFs in there, as well as an ACF model, all tuned for the iPhone.
In the next few posts I’ll blog a little bit about the impact of doing an iPhone port on scenery development. The iPhone is an embedded device; if you go digging for system specs you’ll see that it’s a very different beast from the desktop. The porting process really helped me understand the problems of the rendering engine a lot better, and some of the techniques we developed for the iPhone are proving useful for desktop machines as well.
I just received a series of reports today that certain converted scenery will cause X-Plane to crash with a “bad alloc” error. Basically, this couldn’t have hit us at a worse time. The final 920 was cut a week ago. We physically can’t recut; Austin is on the road, and I am knee deep in it. But there is a possible work-around, and there will be a patch. Here’s the whole situation.
What is a Bad Alloc?
A bad alloc error is an error that comes up when X-Plane runs out of memory. This can happen for two reasons:
- We have run out of address space – that is, there is no more virtual memory left, or
- We have run out of page file/physical memory – that is, we can’t back that virtual memory.
The first case is by far the most common – you’d only hit the second if you are on Windows with a fixed-size (but small) page file. (Hint: if you have a fixed size page file, make it big!)
X-Plane can run out of memory for many reasons – everything that runs in the sim uses memory, and the amount used depends on what area you are in, what rendering settings you pick, and what third party add-ons you use. While I’d like to someday reach a point when the sim tells you gracefully that it’s out of memory, it will always be a fact of life that at some point (hopefully an absurdly high one) the amount of stuff you’ve asked X-Plane to do will exceed how much memory you have.
(If you are thinking 64 bits, well, that will just change the problem from a crash to a grinding halt when we run out of physical memory.)
We see bad allocs when there are too many third party add-ons installed (XSquawkBox is a particular pig because it loads every CSL on startup), too complex scenery, and it can also be caused by drivers not efficiently using memory. (This is particularly a problem on Vista RTM.)
The Bug
When X-Plane creates a curved airport taxiway, it allocates a temporary memory buffer to hold the intermediate product of the pavement. The size of that buffer depends on the complexity of the curve it is processing and a constant, based on the maximum curve smoothness.
In 920 I provided an option to crank up the curve smoothness in X-Plane. In the process, I increased that constant factor by 4x, which causes X-Plane to hit its memory ceiling on layouts that used to be acceptable. You’ll see this problem more often on:
- Bigger, more complex layouts.
- Configurations that were already chewing up a lot of memory.
- Machines with less address space (Windows without /3GB, older Mac OS X operating systems.)
What really suckered us about this bug was that it comes in a form that looks almost the same as a driver issue we’ve seen with ATI drivers on Windows — we’ve seen strange forms of memory exhaustion on ATI when shifting scenery with high rendering settings. So we didn’t realize that this was something new until G5 users reported the bug (making us realize it wasn’t a driver thing).
What To Do
The bad news is that we can’t do an RC5 – we’re out of time. But – there will be a patch – relatively soon. This bug is on the short list for a patch to fix 920.
In the meantime, there is actually a work-around. By coincidence, some of the internal rendering engine constants are viewable via the “private dataref” system — basically a series of datarefs in the sim/private/… domain that I use for on-the-fly debugging. The dataref that matters here is:
sim/private/airport/recurse_depth
If you load up DataRef Editor you’ll see it has a value of 12 . That’s too high. Changing it to 10 will allow otherwise problematic airports to load.
I will try to post a plugin in the next 10 days that sets this dataref to 10 on startup, effectively patching the problem. This will also limit the maximum smoothness of curves – but my guess is that if you see the crash (not all users do) then you can’t run on the max airport curve setting anyway.
Of course the next patch will contain a real solution: a more efficient memory allocation scheme!
Two random and unrelated notes:
First, RC4 is going out as is, despite the engine modeling changes being incomplete. Basically we now have a more sane approach to the engines themselves, but no FADEC control. FADECs are on the short list for the next update. Sometimes we just run out of time – not every release can have everything.
Second, a note on autopilot customization – I am party to a fair number of questions about whether the plugin system can be used to make subtle changes to the autopilot logic. The answer is of course: no. If you really want something different for an autopilot, you’d have to replace the entire “top-half” set of logic and drive the flight directors yourself – in this situation you are responsible for:
- All modes and mode changes based on conditions.
- The actual selected flight envelope to achieve the desired AP setting.
But you are not responsible for driving the trim and yoke, which are done by you setting the flight director.
Why can’t you just override one specific behavior? It’s an issue of infrastructure.
Fundamentally, the autopilot only does a few certain tricks. If it were capable of doing customized behaviors, you’d already see it, in the form of a dataref or (more likely) a Plane-Maker setting. Basically there is no generality to the autopilot that we secretly have inside the code but don’t expose.
Will there be a more general autopilot someday? Maybe – I don’t know, I don’t work on that code. But the plugin system has always aimed to make it possible to do anything, but not necessarily easy. In particular, the plugin system doesn’t aim to make your development easier by recycling the simulator itself as a convenient library of lego bricks. In the end of the day, X-Plane is an application, not a library. If it were a library, that would be lots of fun for third parties, but it is not.
I don’t like to delete/reject people’s comments, but I do not want new users to find this blog, see tech support requests, and add their own, only to have them sit unanswered for, well, ever.
If you bought X-Plane from Laminar Research, the tech support contact info can be found here:
http://www.x-plane.com/contact.html
If you bought X-Plane in a store, the distributor will have their own tech support contact info on the box.
From this point on, I am going to reject requests for tech support that come in the comment box. If you need help with X-Plane, use the email or phone number found on the contact page above!
Posted in News
by
Ben Supnik |
I believe I am getting close to a possible solution for the dreaded “Framebuffer Incomplete” errors – these error messages pop up when X-Plane starts, and you end up quitting.
If you meet these criteria, please contact me:
- You have an ATI card that has shown this error in the past.
- You can put on the latest Catalyst drivers. (I know a lot of you have put on older drivers to work around this.)
- You can run X-Plane 920 RC2.
If you’re in this crew, please email me at my XSquawkBox email address!
The rub is: despite having four machines with ATI cards, I never see this error. So I need to send you a build to get close to a fix!!! Let’s swat this bug for real!
As 920 beta finishes up, I am working on some WED features. Future WED updates will be small and more frequent; I think it’s more useful to get at least some features into WED quickly, rather than holding them until I have a huge update.
So this list is short – that doesn’t mean that other features won’t happen – they just won’t happen as soon. In particular, I am very aware that WED needs better taxiway sign editing and better polygon editing. Those will have to wait though.
WED 1.1 will provide overlay editing. WED will not be a replacement for overlay editor – Marginal has done a really great job with his tools. However, having overlay editing in WED will allow people making airports to see complete apt.dat 850 data and overlay data at the same time. This is particularly useful for authors making custom scenery where the apt.dat format is augmented with custom DSF overlay pavement and lines.*
WED 1.1 will have 3 features:
- Ability to edit these DSF overlay types: object placements, facades, forests, object strings, draped lines, and draped polygons (both tiled and textured with ST coordinates).
- Very limited preview of those types. I know you will be able to see the texture for a draped polygon for orthophoto placement. I do not know if I will even have OBJ preview in 1.1. Editing will not be WYSIWYG. It will be more CAD-like.
- Import and export of DSF overlay types to DSF overlay files.
Note that while roads and beaches are technically allowed in overlays, they are not on the list. The reason is that right now both of them require elevation data in the road and beach itself. Since WED doesn’t have a base mesh, it can’t sanely provide this information.
Eventually we will have some way to “drape” roads – at that point it will make sense to provide WED road editing too. But let’s not delay at least some overlay editing that long!
I don’t know exactly how long this work will take – my rough guesstimate is about 2 weeks. But…that depends on my working on WED for two weeks straight without interruption!
* Every type of element in apt.dat can also be created with custom-provided artwork and an overlay DSF — draped polygons for taxiways, draped lines for taxiway lines, object strings for taxiway lights, etc. The idea is to provide a way for authors who want to extend realism beyond the scope of apt.dat 850 to insert custom artwork. Apt.dat 850 is not a modeling format, so you cannot provide PNG files with it.
If you look at the LOWI demo area, you’ll see that some of the pavement in that layout is in the apt.dat file, but some pavement is in the DSF overlay. Creating this demo area required a bunch of DSF2Text hacking by Sergio and myself. With WED 1.1 it will be possible to do this completely using WED.
We’re about to do something strange: any time now, Austin should announce 920 beta 1.
But what happened to the 902 beta program?
The answer is simple: it turns out we don’t need it.
Both 901 and 902 were tiny releases whose sole purpose was to add new languages to X-Plane. (901 added French/German, 902 Russian). The idea was to get our foreign distributors a localized version of the sim faster than we could do the next major patch.
Well, 920 is here, and the Russian port is still being debugged, so 920 will contain Russian and also a huge host of new features. There will never be a 902 final; simply update your beta to 920 when it’s out – any tiny changes in 902 are baked into 920.
Don’t Panic
As always, my advice for beta 1 is: don’t panic. Remember that we are a small company, and thus we have a small number of computers between all of our employees. The first few betas usually involve one or two serious bugs (the sim explodes and sets your computer on fire, etc.) that only happen on the one hardware configuration none of us have.
If you are a user, consider waiting for a later beta, or upgrade a copy of the sim.
If you create third party add-ons, please get a copy of the beta early and start filing bugs! It is much easier for us to fix compatibility bugs when we get the reports early.
Multi-Lingual
A number of users have offered to help translate X-Plane. With 920 we finally have the “new” localization infrastructure in place; I will finally be able to get users started on this process.
