Every time I work on a new X-Plane feature, I do a combination of:
- Reorganizing and cleaning up old code.
- Adding new features.
- Tuning performance for this new environment.
My experience has been that the investment in cleaning up old code is more than paid for by faster, easier development of new code – it’s easier to code in a “clean” work area.
As part of my work on 930 I am refactoring and optimizing how we set up pixel shaders. I’m not sure if there will be any framerate benefits in the short term, but in the long term there is definitely an advantage to being able to set up the most optimal shader configuration for any situation.
(Since most of what we draw – OBJs, airplanes, DSFs) can be created by users, we never really know what we’ll be drawing…the set of art content X-Plane can handle is almost unlimited. So it is up to shader optimization code to “find” the optimal setup for a particular stew of OBJ attributes, textures, etc.)
The short term fall-out during beta is unfortunately a certain amount of pain. It’s likely that these changes will introduce graphic quirks with certain combinations of planes. These are fixable! The important thing is: if you hit a graphics bug with a particular plane or scenery pack in 930 (whenever we get to beta – we are not in beta yet!) and that bug is not in 921 – report it! It may be that the optimizer is being too aggressive with a particular combination of settings and turning off some critical feature.
I will run the new shader optimizer code through just about every scenery pack and airplane I can find, but invariably there is some magic trick in a third party plane on the .org that I won’t have.
One thought for creating fast content: alpha is expensive! Or rather, let me rephrase that to: if you are not using the alpha channel of your texture, you should not have an alpha channel in your texture.
(For PNG this means stripping the alpha channel off, rather than having a solid 100% opaque alpha channel. For DDS this means using DXT1 with no transparent pixels.)
The new shader optimizer detects the case where alpha is not being used and sets up a more optimal code path. (The old shader optimizer did that too, but only some of the time – in the new code, we will always take this optimization.)
Having alpha blending enabled can inhibit “early-Z” optimizations on modern GPUs, and also require a more expensive blending operation in the framebuffer.* So if your model doesn’t use alpha, strip the channel.
* Some newer graphics cards recognize 100% opaque alpha and provide fast write to the framebuffer. But even if early-Z-type optimizations become alpha friendly, there will still be optimizations we can make in the sim if we hit the no-alpha case.
