I commented about this once a long time ago, but with DirectX 11 cards coming to market, I think some clarification may be in order. What exactly is the relationship between DirectX, OpenGL, your graphics card, and X-Plane?
OpenGL and DirectX
OpenGL and DirectX (well, technically the Direct3D part of DirectX) are both:
- Specifications for how an application requests that graphics be drawn.
- Specification for what will be drawn by a library or video card when those requests are made.
(Okay that’s a gross simplification, but it will work for now.)
But DirectX is also something else: it specifies what the hardware must do. That’s different from OpenGL. You can have an OpenGL compliant renderer that uses the CPU for everything difficult. It will be slow, but correct.
Extensions and Versions
Both DirectX and OpenGL have version increases, and the new version increase specifies new functionality. But OpenGL also has extensions. While normally new features come in a new spec verison, OpenGL’s extensions allow OpenGL implementations to pick up new functionality “a la carte”. OpenGL implementers can pick and choose what they add.
When Features Show Up
The trend in game GPUs has been for new features to show up in the DirectX spec first, then become available in OpenGL via an extension, and then make it into a future core OpenGL version. For example, most DirectX 10 features were available once DX10 hardware was released, in the form of extensions.
Sometimes the features flow in the opposite direction. For example, ATI’s tessellation technology may make it into the DirectX 11 spec, but is already available as an OpenGL extension.
How This Affects X-Plane
To be blunt, X-Plane is not an early adopter of GPU tech. We are a small company so we have to prioritize our feature work carefully, and there’s strong motivation to prioritize a feature that helps all users over a feature that helps only users with certain hardware.
So by the time we code a hardware dependent feature, the feature is usually available in OpenGL…I can’t think of any cases where not using DirectX has held us up.
For performance, DirectX vs. OpenGL doesn’t really matter – both provide access to the “fast path” of the harware – this is the code path where the GPU runs its fastest. At that point, it’s a question of hardware, not OpenGL vs. DirectX.
So X-Plane uses OpenGL, but both are fine for rendering engine development (unless you need to be cross-platform), and both provide reasonable access to video card features for X-Plane.
I don’t usually link to non-X-Plane blogs, but I really liked this pair of posts:
http://distractible.org/2009/11/05/top-10-ways-to-annoy-your-doctor/
http://distractible.org/2009/11/08/top-10-ways-doctors-can-annoy-patients/
If you live in the US, you’ll definitely appreciate it…the lists are funny and yet have a seed of painful truth in them.
So I decided to try to create my own lists.
I am only tangentially related in tech support – Randy takes on most of the work with some help from Jack. Sometimes very weird reports get escalated to me. (And most of the “let the report sit for a week” comes from me not having time to dig in.)
Anyway, please take these with a grain of salt – they’re meant to be funny and exagerated. Most of our users are very, very helpful in tech support calls, despite the fact that, if you are talking to tech support X-Plane is already hosed. And Randy puts forth some amazing acts of patience in the face of some of the requests he gets. My hope here is only to show that there are two sides to the frustration in a tech support incident, and we’ll all be happier if we can see the whole picture.
Five Things You Can Do To Annoy Tech Support
1. Be As Angry as Possible
Threaten to switch to Microsoft Flight Simulator. Drop the F word a few times. KEEP CAPS LOCK DOWN FOR THE ENTIRE EMAIL. Tech support definitely responds better to users who are angrier – you don’t want to get sub-standard service because you were too nice, right?
2. Omit Information
If you have a second graphics card made in Kazakhstan, over-clocked and running hacked drivers you got off of the pirate bay, don’t tell us. If your computer regularly catches on fire, be sure not to mention that. Did you recompile the Linux Kernel yourself after letting your pet monkey edit the thread scheduler? It’s best we not know.
Extra credit: report a truly bizarre problem, provide no details on your customized configuration, wait a week and tell us how you fixed it by removing a third party program that “enhances” sound or graphics. Priceless!
3. Don’t Include Past Emails In a Thread
Be sure to delete any past information from your email. Change the subject of the email so we can’t tell what the original issue was. If you have more than one email, send replies from different addresses. A perfect reply would be “That didn’t work” sent from an email address that you haven’t used before, without your name included.
4. Email the Last Person You Talked To.
If you just finished up sorting out a shipping problem with the shipping guy, ask him how to create a plugin. If you just got info from the developers about UDP, ask them why your credit card was charged the amount it was charged.
5. Bring Up New Issues In the Middle of Old Ones.
To do this just right, wait until the thread between you and tech support is pretty deep into the meat of a complex issue. Then throw in another paragraph about something else that’s gone wrong. To perfect this technique, try to pick a new problem that the person who you are emailing with isn’t equipped to handle (see point 4) and keep the report vague (see point 2). You can repeat this technique to stretch out a tech support incident indefinitely.
Five Ways Tech Support Can Annoy You
1. Make the User Reinstall the OS
Reinstalling the operating system fixes approximately 0% of user problems, but it takes a really long time, and is almost guaranteed to screw something else up, usually something that wasn’t broken and isn’t related to X-Plane. If a user is a little bit annoyed, this is a great way to pour gasoline on the flames.
This is really a special case of the general strategy “ask the use to do something time consuming, annoying, and unlikely to help.”
2. Forward the User a Huge FAQ, None of Which is Relevant to the Problem
Everyone likes form letters and impersonal service. The FAQ should be badly written, badly formatted, confusing to read, and preferably not accidentally contain the real solution to the problem. If the solution to the problem is in the FAQ, don’t tell the user where in the FAQ to look.
3. Wait a Long Time Between Replies
Tech support incidents are like fine wines – they get better with age. To allow the user’s annoyance to bloom into a finely honed rage, be sure to let each email ‘sit’ for a week before replying. This works especially well if your response is just to ask another question, setting the user up for another week’s delay.
4. Blame Some Other Component
The modern PC is built by approximately 600 different vendors. Blame one of them. The beauty of this strategy is that it is one that can be used by every vendor who provided software or hardware for the PC. Also, because quite often the problem really is with another component, you can claim this with a straight face.
Tip: blame the graphics card maker – ATI and NVidia do not have the resources to pursue every complaint that an over-clocked graphics card running the latest patch to some simulator written by two guys in their bedrooms crashed with the drivers visible somewhere in the callstack. Put the blame on the GPU makers – they don’t have the resources to refute you, no matter how bogus your claim.
5. Forward the User’s Issue Around the Company Until It Gets Lost and Dropped
Everyone in the company has to be in on this strategy for it to work – if one of your idiot coworkers actually solves the user’s problem, well that defeats the purpose. This strategy can be combined with (3) and is sort of a riff on (4) – once the user complains that they got dropped, blame everyone else in the company for the mis-communication.
This will be a little bit “off topic”, and I am normally pretty adamant about not blogging (or even talking) about XSquawkBox. This is because XSB is not something I do as part of my job for Laminar Research, and it is also something that I no longer have time for. Thus my normal highest priority is to make sure that no XSquawkBox users expect timely support or expect this from Laminar Research.
So as I am about to blog about all of the new and cool things coming in XSquawkBox 1.3, let me first make this painfully clear:
XSquawkBox is a piece of code that Wade and I write in our spare time. After finishing our regular job of coding, rather than sit back and read a book or take a walk in the park, we go back to our computers and write yet more code. We don’t make any money off of XSB, and no one pays any money for XSB.
This type of freeware development has certain constraints: there is no time table, XSB will be on the back burner when real work comes up or when real life comes up. There is no support. There are no guarantees of features or functionality. If you don’t like those terms, I will issuse you a full refund and you can use a different piece of freeware.
Okay – that was a little bit over the top. We want people to enjoy XSB – otherwise we wouldn’t have published it. And 99.999% of XSB users are very understanding and appreciative of the development situation.
With that in mind, I can’t resist posting some of what is coming in XSB 1.3 – I think it’s going to be a really strong release. 1.3 will have the bug fixes people are waiting for, including a fix for the dreaded noise on push-to-talk on Windows. Also coming:
- Wade programmed the server list to auto-populate off the net. How did we live without that?
- COM2 can tune into voice channels too. COM2 has its own hardware selection for those with multiple sound cards or USB headsets.
- You can turn on “labels” for traffic. I actually hate this feature, but I programmed it anyway – it’s optional. I’ll post why I did it some other time.
- XSB can connect to itself for users with multiple X-Plane visuals. Simply run XSB on every computer, log in from one (the “master”) and then connect to the master from each visual (the “slave”). You’ll have traffic visible across monitors.
And of course the best feature of all (for me): Wade is doing builds. 🙂 People owe him a big thank-you..without him there would simply be no 1.3. I definitely don’t have time for it…I maxed out my XSB time for a while contributing some of the features.
When will 1.3 go beta? I don’t know…ask Wade. Wait – don’t ask Wade. He’ll get to it when he is able!
Tom had a good question that others have asked me too: why not ignore missing scenery resources? Why does X-Plane act so cranky?
Ignorance Is Bliss
We have tried the other approach: ignore missing art assets. ENV based scenery in version 7 did not require custom objects to actually be available – missing objects were ignored.
When I was working on the ENV reader for version 8 (the ENV code needed to be retrofit into the new rendering engine) I found to my surprise that virtually every ENV-based custom scenery pack I looked at was missing at least a few of the OBJs that the ENV referenced! I don’t know how this happened – it seems that in the process of working on scenery, authors started to “lose” objects and simply never noticed.
Quality Control
When we developed DSF we had a chance at a clean slate: there were no DSFs in existence so we could set the rules for art assets any way we wanted. So we picked the harshest rule possible: any missing art asset was illegal and would cause X-Plane to refuse to load the scenery package, with no way to ignore the error. Why be this rude?
- Missing artwork failures are 100% reproducible – you don’t have to try your package more than once to see the problem. If you are missing an art asset, you will have the failure every single time you run.
- The error is found on load – you don’t have to fly over the art asset to discover that it is missing.
- Therefore if an author tests a scenery package even once, even in the most trivial way, he or she will discover the missing art asset.
- Once the error is fixed, it is fixed forever, so a scenery pack that passes this quality control measure in development will be just fine “in the wild”.
- This rule has been in place since 8.0 beta 1 for DSFs, so there are no legacy DSF files that would have this problem.
Libraries
There is one special case worth mentioning: a scenery pack might reference an art asset in another scenery pack, and that other scenery pack might not be installed. This is why the library file format allows for “export_backup”. (Read more here and here.) Export_backup is your scenery pack’s way of sayingg “only use this art asset if you can’t find it somewhere else. It lets you provide emergency art-work in the event the other library is not installed.
What should you use as an emergency backup art asset? It could be anything – a big floating question mark, an empty object, a poor approximation of the desired art asset. But my main point is that responsibility for location of art assets lies with the author of a pack – so if you make a scenery pack, be sure to provide backups for any libraries you use.
(If you use OpenSceneryX, the library comes with a “developer pack” – read more here. Basically they already built a “backup” library that you can put in your scenery pack to avoid nasty messages from X-plane when OSX isn’t installed.)
No posts for two weeks…sorry, I’ve been head’s down with next-gen tech. It’s a little bit too early to blog about this stuff.
I was able to fix a few MeshTool bugs, but I have more problem reports, so I might be able to do a MeshTool beta 3 in a few days if things go smoothly.
940 is final – there might be a 941 maintenance release – we’ll know in a few weeks.
Yesterday I blogged about Order Independent Transparency (OIT). That robot is very shiny, but what does this fix in X-Plane itself? Here are two pictures that show the problem in an X-Plane context.
This is the Cirrus jet in X-Plane 9.22.
Pretty, eh? But…look through the right two windows – look at the passenger door on the other side. Note that through the middle window the passenger door is visible. Through the right window, the entire passenger door is gone!
This is the same shot from X-Plane 940, where the problem has been corrected.
The bug you see here is incorrect draw order. In X-Plane 922, the right door (which contains the right-most near window) is drawn before the left door – hence its translucent part destroys the door.
Max fixed this by changing the draw order of the model – the new cirrus draws the inside view of both doors before the outside view of either doors; because the geometry is one-sided he can draw the ‘inside’ first and outside ‘second’.
These two
blog posts explain translucency in a lot more detail.
What X-Plane has now is “order dependent” transparency – if translucent surfaces are not drawn from far to near, you get artifacts like the missing door.
What OIT promises (and that robot demonstrates) is the ability to have translucent geometry and not have the objects behind the translucent parts disappear.
Order independent transparency (OIT): first, the shiny robot.
So first, what’s so special about this? Well, if you’ve ever worked with a lot of translucency in X-Plane, you know that it doesn’t work very well – you invariably get some surfaces that disappear at some camera angles.
The problem is that current GL rendering requires translucent surfaces to be drawn from farthest to nearest, and who is far and who is near changes as the camera changes. There are lots of tricks for trying to get the draw order mostly right, but in the end it’s somewhere between a huge pain in the ass and impossible.
What’s cool about the robot data is that the graphics card is drawing the transparency even if it is not drawn from back to front, which means the app can just shovel piles of translucent triangles into the card and let the hardware sort it out (literally).
X-Plane is currently riddled with transparency-order bugs, and the only thing we can do is burn a pile of CPU and add a ton of complexity to solve some of them partly. That proposition doesn’t make me happy.
So I am keeping an eye on hardware-accelerated OIT – it’s a case where a GPU feature would make it easier for modelers to create great looking content.
This feature is not in the WED developer preview (because I just coded it) but: WED 1.1 will feature “click-to-split” for edges. With WED 1.1 you can option-click the edge of a polygon or line feature (but not a must-be-straight entity like a runway) to insert and drag a split point.
This will hopefully be a lot easier than the current, convoluted, WED 1.0 technique of selecting the two surrounding vertices and picking “split”, then repositioning the vertex.
Hackers: this features is not yet checked into the tree, so … building from source won’t help you. It’ll be available some time in the next week.
I realize as I write this that I am going to get some comments mocking the fact that X-Plane 940 is on RC, um…13. I don’t decide the milestones for X-Plane, nor do I decide the version numbers. If you want to discuss why X-Plane is 940 (and not 930 or 950) and why it goes beta and RC when it does, email Austin. What follows is all about the scenery tools, not X-Plane.
With that out of the way: I have released a WorldEditor 1.1 developer preview. So I wanted to explain in a little bit more detail what the difference is between a developer preview and a beta. Here is an approximation of the standard definitions of “milestones” – they are what I use for WED.
- Development: not all features are coded, no guarantees about bugs.
- Alpha: all features are coded, no bug is so severe that you can’t at least try a feature. (For example, if WED crashed on startup, it would not be alpha, because you could not test saving files.)
- Beta: all requirements of alpha, also no bugs that cause program crash or data loss.
- Release: no open bugs.
This all applies to known bugs. Beta software may crash and cause data loss – it’s just that we wouldn’t have put it out as beta knowing that this happened.
WED 1.1 is still in phase (1) – development, and the build I posted is a developer preview – a cut of whatever code I had laying around. So: I can’t promise it isn’t going to trash your data or crash! Be even more cautious with the developer preview than you would with a normal beta. You don’t want to run a five hour session without saving your work, and you want to be backing up your work often – the “save” command might trash your entire project.
Why do a developer preview if it’s still so buggy? Some users who know how to compile WED from its source code are already using WED 1.1 and they seem to be enjoying it. So far it appears not to be lethally broken. Given that and the fact that most of the uncoded WED 1.1 features are usability and edge-cases, it seemed like the developer preview could be useful for getting earlier feedback.
One last note: the manual is not updated at all, nor is there any documentation on the new features. Let me be clear: no tech support or help is provided what-so-ever. Do not email me, or X-Plane tech support with “how do I use WED 1.1” questions. If you cannot figure out how to use WED 1.1 on your own, don’t use the developer preview.
We’ve made some progress in transitioning XSquawkBox to be under Wade’s primary management – read more here.
