The time has come for me to move on to another pasture. After 4 years as a graphics developer (and more than 8 as a game developer), I have decided to take the plunge and explore something new and different...

Yep, starting Dec 3rd, I will be moving from the ACES team to the Media Center Extender team.  Although somewhat of a sharp direction change from my previous position, the new job is still graphics related but obviously focuses on low-level and embeded technologies. I always wanted to work on something that was more of a driving technology than a singular product. Although this is not within the console environment as I would have initially thought, the Media Center Extender is essentially at the center of the digital home (or at least will be) and it is actually exciting to be part of such a central piece of technology!

Why am I moving on? Well this is a tough question. There is alot of factors, some personal, some professional. But overall, suffice to say that I had reached the point where I needed new challenges. With the new year comming up, the best time ever for a fresh start :)

I do wish the best to the ACES crew... They have alot heading their way, but I also know they can step up and deliver!

The purpose of this post is to address a question that was sent to me in regards to water reflections in general. The question actually is two questions... The first one asks me to explain the difference between the various Water 2.X settings (Low/Mid/High/Max) and why these settings have such an effect on perf. The second question was in regards sd to why dynamic reflections are only on bodies of water and not other wet surfaces (such as a wet runway). I want to keep the answer as simple as possible but at least provide some insight as to how things work and why we have to make some specific decisions some times...

Why no Reflections Elsewhere? 

This is actually a good questions. We do apply "reflections" to the other wet surfaces but the reflection map that is used is static and is not dynamic as with the water. There are a few reasons for this but I will cover the main ones. The approach that is used with water surface reflections is to assume that the water is a flat surface and to treat as if it was a plain mirror. With this assumption, we can generate a reflection map simply by reflecting the camera around the plane that is generated by the water surface and taking a "screen shot" from that point of view. This is a really nice and easy way to accomplish water reflections and when dealing with waves, we simply distort the lookup into this reflection map. This is far from perfect but does the job really well in this case.

But what about adding reflection maps on everything else? There are a few problems with this in general. The first one was implied in the first paraghaph "to assume that the water is a flat surface"... This is not generally true for general objects and this method breaks down rather quickly as soon as a surface is not planar. The next best alternative is to use a cubemap as a reflection map, but this automatically increases the cost by a factor of 6x. Going back to the specific case of runways and wet pavement, in the majority of cases, we could likely assume a flat surface. But there is another overall problem (which is also a problem with water in genral). What if there is more than one planar surface in view? What to do in the case where you can see two lakes that are at a different altitude within the same view? The correct approach in this case would be to generate a seperate reflection map for each planar surface that is visible. But as you can imagine, that would be impractical and would make the cost of rendering the reflection maps unpredictable. For water, we simply look at what is in view and make a good faith guess as to what is the predominent body of water and use its elevation to generate the water reflection map.

Also, in the case of water, we have nice vector data which outlines the contour of the body of water, making it easy for us to determine the outline of the bodies of water. For generic reflective materials, it is more difficult. We do have similar information for airport related asphalt but not necessarily for other reflective surfaces in the game. Dynamically generating a reflection map is something that can get hairy real quick so it was decided that, at least for FSX, we would focus only on water reflection.

Visual Results for the Various Detail Settings 

Instead of writing a long paragraph on this, I think a picture is worth a thousand words. I have captured a snapshot of the same scene using the various 2.x water settings. In the caption below the image I indicate what is rendered inside the reflection map and I've also turned on a debut feature which shows the content of the reflection map in the top-left corner. I will not go into the details of where all the performance goes, but you can likely extrapolate from the amount of detail in each map that the Max setting is going to cost LOTS MORE than the Low setting.

Water 2.X Max - All is rendered, equivalent to rendering the whole scene twice with the exception of a few optimizations which take advantage of the autogen and batching LOD system to reduce the overall number of draw calls.

Water 2.X High - Only the aircraft, full sky (with clouds), terrain and non-autogen scenery is rendered.

Water 2.X Med - Only the aircraft, full sky (with clouds) and non-autogen scenery is rendered.

Water 2.X Low - Only the aircraft  and sky (without clouds) is rendered.

About time hunh? I know, acceleration is already out and I was not even finished with the overview of all the features I worked on for my blog. That's life for ya...

Before I start explaining anything, the two videos below compare the DX10 and DX9 water effects...

See the difference? Well I swear there is one, and the quality of these video clips sure doesn't give it justice. Of course, those that remember this magical "PR mock-up" screen shot showing what DX10 could be, you probably say the dynamically moving water with waves crashing on the shoreline,... Obviously this did not happen. Probably the best way to approach this topic is to start explaining what happened and then go through the things that didn't happen and explain why.

What Did Happen in DX10

Most of the work for DX10 was kept as small size chunks. This was on purpose to try and keep our work balanced between the various features. But overall here is a breakdown of the improvements made:

• Performance improvements to the generation of the reflection map. Turns out we were doing alot of useless things to generate this low-resolution texute. This is still not perfect but in some extreme cases it did create a 20% performance improvement on my DX10 system.
• Significant enhancements to the water shader. For the most part this includes the addition of more bump for the water so the bumpiness appears less repetitive and more dynamic. I have also added a new "detail bumpmap" which only kicks in when the viewer is closeby. This is to compensate for the lack of resolution of the bump when on the water (which created really blocky lighting and reflection). This texture does fade out with distance to avoid any aliasing problems.
• Also, I added support for simple whitecaps. At this time, it isn't done through dynamically generated particles or other geometry but it is actually done procedurally within the pixel shader based on an estimation of the local turbulence. It actually looks quite nice considering the simplicity of the algorithm.
• I also started the implementation of the framework needed to allow the variation of the water settings on a per-waterclass basis. The code that is in place is not complete and was disabled. This feature came in too late and was too risky to turn on so we did have to "ditch it" at the last minute.

What Didn't Happen in DX10 :(

Actually, the main thing that did not happen and which is the main feature that is noticed is the dynamically waving water. This was indeed in the initial plans for SP2/Acceleration. Actually, this was even in the initial FSX plans but at the time the only solution was to do this on the CPU and seeing that it would consume 30-50% of the CPU on complex scenes, we decided to postpone this feature until it could be done on the graphic hardware.

Of course, DirectX 10 was a prime opportunity for this. However a few problems caused us some grief. The initial plan was to leave the water geometry as-is and let the GPU tesselate the geometry within the new geometry shader. Well once the real hardware came out, it turned out that geometry shaders we not performant enough to accomplish this. The second option was to pre-generate the water geometry but let the dynamic update happen on the GPU. The problem in that case is that it would roughly double the terrain/water geometry memory footprint.

In other words we were doomed either way and deemed this was just too risky at the moment, at least until we could fully investigate the consequences of each option and to see what else could be done.

Yay! Time for another post about some of the upcoming graphical changes in FSX SP2/Acceleration. This time I take a look at the topic of Bloom (as in DX9) vs HDR (High-Dynamic Range which is DX10 only). From some of the forum posts I have read, there seems to be alot of speculation as to what the difference really is and as to whether or not there is actually any difference (you just have to love those conspiracy theories). The point of this post is to give a side-by-side comparison of the two approaches and then I will make a brief talk as to what the differences actually are from a more technical point of view...

The two videos below compare the DX9 Bloom with the DX10 HDR...

If you take a close look at the videos, you can see some visible but subtle differences between the two clips... But the hot question, is what really happens behind the scenes...

Although the techniques used in DX9 and DX10 are different, they both aim to reproduce the same effect. To keep this simple, bloom or HDR is the effect that occurs when lights of various intensities affect the viewer (generally by darkening or oversaturating the image). The best way to picture the effect is to imagine that you are driving on a bright sunny day and that you approach a dark tunnel. From a distance, the inside of the tunnel appears black, which is due to the fact that the bright intensity of the sun forces our eyes to adjust themselfs to the ambient light intensity. This means that even though there is light inside the bridge, our eyes are adjusted to brighter intensities and the lesser intensities get filtered out (essentially the same thing as playing with exposure setting on a camera). The reverse is also true... If you are inside the tunnel looking towards the exit, it will generally appear quite bright, mostly white and washed out. This is due to the reverse process where the overall ambient lighting is low and the eye adjusts itself consequently meaning that any bright source of light will have a tendancy to appear saturated.

The exact detailed technical description of what is HDR and how it can be repsented can be quite long. Maybe the beat and easiest is to simply refer and quote the relevant Wikipedia article (http://en.wikipedia.org/wiki/High_dynamic_range_rendering):

Preservation of detail in large contrast differences
One of the primary features of HDRR is that both dark and bright areas of a scene can be accurately represented. Without HDR (sometimes called low dynamic range, or LDR, in comparison), areas that are too dark are clipped to black and areas that are too bright are clipped to white. These represented by the hardware as a floating point value of 0.0 and 1.0 for pure black and pure white, respectively.

Graphics processor company nVIDIA summarizes one of HDRR's features in three points[4]:

Bright things can be really bright
Dark things can be really dark
And details can be seen in both

Accurate preservation of light
Without HDRR, the sun and most lights are clipped to 100% (1.0 in the framebuffer). When this light is reflected the result must then be less than or equal to 1, since the reflected value is calculated by multiplying the original value by the surface reflectiveness, usually in the range 0 to 1. This gives the impression that the scene is dull or bland. However, using HDRR, the light produced by the sun and other lights can be represented with appropriately high values, exceeding the 1.0 clamping limit in the frame buffer, with the sun possibly being stored as high as 60000. When the light from them is reflected it will remain relatively high (even for very poor reflectors), which will be clipped to white or properly tonemapped when rendered.

Likewise when light passes through a transparent material, the light that passes through has a lower brightness than when the light entered. An example of the differences between HDR & LDR rendering can be seen in the images to the right, from Valve's Half-Life 2: Lost Coast which uses their game engine "Valve Source". In the example pictures, with low dynamic range rendering, much less light passes through the stained glass, causing the scene to be darker. The reason for this is that when light passes through a transparent material, it lowers the light’s brightness. In a simple example, say the stained glass can block 40% of the light. Since the highest value of the low dynamic range light is 1.0, this means a brightness of 0.6 is illuminating the other side. The high dynamic range light is perhaps 100, which means a brightness of 60 is illuminating the other side.

As I have mentioned, both the DX9 and the DX10 approach aim to accomplish the same goal but use different approaches.

DirectX 10 VS DirectX 9:

The easiest implementation is actually the one taken under DirectX 10. As mentioned above, true lighting intensities cannot be represented by a simple 0->1 range and DX10 guarantees floating-point texture support. The implementation takes advantage of the this feature and do all our rendering directly to a floating point texture. We then use this texture and apply standard texturing operation such as a blur filter (to create a bloom/glow) and a star filter which is used to crate the stat-like patterns that generally occur when the light traverses a imperfect medium such as glass.

Under DirectX9, the back-end (bluring and filtering) is mostly the same. However the main difference is that we do not use floating point textures. I can already hear the conspiracy theories right now that we didn't use the DX9 support for floating point textures to force users to upgrade to Vista and purchase new hardware. This is far from true....

The main problem under DX9 is that support for floating point textures was introduced late and is an optional feature (although most Shader 3.0 cards have some support for it). In addition, alpha-blending and filtering on floating point textures is not required and most cards under DX9 do not support these features which are not a requirement but can make a huge performance difference when we do the actual bluring and filtering passes (under DX9 we would have to potentially filter the texture manually wihin the shader, not the most efficient approach). Since proper floating-point texture was so sparse under DX9 and that DX10 had guaranteed support for the features we needed to implement proper HDR, we decided to keep the floating point implementation for DX10 only.

So what do we do under DX9? We seperate our Bloom rendering into two distinct passes which are only applied to blooming objects. In the first pass, we capture the color of the pixel as it would occur during regular rendering. In the second pass, instead of capturing the color of a pixel, we capture its intensity (which is in essense a multiplier to the base color). We then use these two sets of information to complete the bloom filtering in a similar way as it is done with the DX10 HDR. The main advantage of using this approach is that it can be implemented on any video cards that has support for shaders and render targets. There are a few drawbacks:

• The intensity map is sampled at a lower resolution (1/4 resolution) in order to optimize bandwith
• There is a small overhead due to the need of having to render two passes for any Bloom emitting object.
• Using a 8-bit value to represent the intensity does not give us as much fine grain detail as the use of a floating point texture. Consequently, the DX9 Bloom has a tendancy to get "hot" really fast and has less of the warm glow feeling that the DX10 HDR effect gives.

We also had the front page of GameSpot (http://www.gamespot.com/pc/index.html?navclk=pc) on Monday but looks like they moved on to another title. However they do have a page with lots of goodies (videos, wallpapers,...) at: http://www.gamespot.com/pc/sim/flightsimulatorxadrenaline/index.html?tag=result;title;1

Apparently, saying "could have been implemented on DX9" in my previous post in regards to VC self-shadowing stired all sorts of drama on some of the user forums. Although the statement is accurate, I did not explain in more details WHY this was not done and why we kept this feature for DX10 only. This post is not intended to be harsh but a mere clarification of why the decision was made. My tone may seem somewhat pessimistic but this is mainly due to frustration from the fact that some of our fans seem to be on a constant quest to crucify us no matter what we do.

Back to the topic of why self-shadowing is only present on DX10, I was really quick and vague into giving actual reasons and wanted to be true and honnest in my statement, which apparently got taken out of context and distorted... Since the VC self-shadowing is essentially another form of shadow mapping as done with the exterior, it could have been implemented on DX9. However, there are two reasons why the self-shadowing of VC was kept as a DX10 features (beyond the force people to upgrade conspiracy theory).

• The first reason was briefly stated above which was for performance reasons. If we were to release this feature on DX9 and drop performance, well we would get crucified for doing so. Then again, I was being honnest and did say such a feature could have been done on DX9 but would hit performance significantly, yet we still get crucified. No matter what I say here, it is a loose-loose scenaro at least from the perspective of some of our fans...
• The second reason, which was not mentioned in my original post, is in regards to visual quality. Under DX9, the shadowmap resolution used is significantly lower and the type of filtering we can use is also fairly limited. This yielded some really blocky looking shadows within the VC. DX10 does give us more options and we were able to use a larger shadowmap for the interior and also use a high quality filter which allowed the shadow to be of good quality. Yet again, if we released the low quality VC self-shadowing, we would have been crucufied for doing so...

The first point that is worth mentioning here is that SP2 (and therefore Acceleration) do introduce a new slew of performance improvements. These improvements are various but the bulk of the work focused around the improvement of our scenery/autogen batching technology. These goals were main in order to reduce the number of “draw calls” (number of times we ask DirectX to draw something) made to the hardware as the overhead involved is actually quite significant and is one of our major bottlenecks (especially on multi-core machine where other background tasks are spread across various cores). I do not have specific numbers on this and millage will generally vary based on settings and location. But overall, based on our test suite, the improvements offset the costs that came with some of the architecture changes we had to make in order to support DX10 and in some cases goes a little further and gives a reasonable performance boost.

Of course, the question on everyone’s mind is “But what about DX10?”. To start, it might be good to set some context. A recent article on HotHardware.Com actually looked at some of the new DX10 releases and compared the performance to their DX9 counterpart. Overall, for most of the titles, the performance was lower. The consensus seemed that this drop was likely due to the addition of several visual features which take advantage of the new DX10 hardware. Here is a snippet from the article which summarizes well the content of the overall article and the conclusions that are making.

From:http://www.hothardware.com/articles/The_State_of_DirectX_10__Image_Quality__Performance/?page=1

The DX10 exclusive effects available in the five games we looked at were usually too subtle to be noticed in the middle of heated gameplay. The only exception is Call of Juarez, which boasts greatly improved graphics in DX10. Unfortunately these image quality improvements can't entirely be attributed to DX10 since the North American version of the game -- the only version that supports DX10 -- had the benefit of a full nine months of extra development time. And much of the image quality improvements in Call of Juarez when using DX10 rendering were due to significantly improved textures rather than better rendering effects.

Our test results also suggest that currently available DX10 hardware struggles with today's DX10 enhanced gaming titles. While high-end hardware has enough power to grind out enough frames in DX10 to keep them playable, mid-range hardware simply can't afford the performance hit of DX10. With currently available DX10 hardware and games, you have two choices if you want to play games at a decent frame rate; play the game in DX9 and miss out on a handful of DX10 exclusive image quality enhancements, or play the game in DX10 but be forced to lower image quality settings to offset the performance hit. In the end, it's practically the same result either way.

While the new DX10 image quality enhancements are nice, when we finally pulled our noses off the monitor, sat back and considered the overall gameplay experience, DirectX 10 enhancements just didn't amount to enough of an image quality improvement to justify the associated performance hit. However, we aren't saying you should avoid DX10 hardware or wait to upgrade. On the contrary, the current generation of graphics cards from both ATI and NVIDIA offer many tangible improvements over the previous generation, especially in the high-end of the product lines. With the possible exception of some mid-range offerings, which actually perform below last generation’s similarly priced cards, the current generation of graphics hardware has a nice leg-up in performance and features that is worth the upgrade. But if your only reason for upgrading is to get hardware support for DX10, then you might want to hold out for as long as possible to see how things play out.

My point of view is similar. The two main components in my opinion for poor performing DX10 titles are the abuse of DX10 features and the lack of maturity of DX10 drivers...

The second aspect, well, we don’t really have control over. Hardware manufacturers are dealing with new architectures and a totally new driver model. It will likely take a while for the DX10 drivers to take full advantage the hardware as DX9 drivers are today.  When it comes to the abuse of DX10 features, it’s plain simple. The hardware does allow you to do more in terms of flexibility, but this does not mean that this is all free. Increasing shader complexity, bumping up texture sizes, … All this does add up and even if the new DX10 hardware is faster, that it is still more than it can handle. So most of these games does perform poorly mostly because they decided to sacrifice performance for eye-candy.

If you read Phil Taylor’s Blog, you probably already have the information I will post below. But essentially, here are two shots of SP2 running on the same system and flight settings. The only difference is whether we used DX9 or DX10. Here are the two screenshots to show the performance improvements (with our new visual improvements such as water and bloom turned on), taken on a 2.4 Ghz Intel Core Duo, with 1GB of RAM, and a GeForce 8800 GTX.

DX9 ( 24.1 FPS, 30 set as goal )

DX10 (30 FPS, 30 set as goal )

So roughly, this is about a 20% performance increase. In fact, as far as we know we are the only title so far that does benefit from a performance increase under DX10. There were several things that had to be factored in our design but overall the main problem we had was a time and resource constraint and we had to aim for a smaller set of features that gave us the best bang-for-the-buck.

I know some are disappointed and this probably stems from two reasons. The first part being the overall level of hype and expectation towards the new DX10 hardware. The fact is that the hardware cannot necessarily do more in terms of computing power (well slightly more) but only drops several of the barriers that were preventing developers to express more creative freedom and explore new rendering techniques and algorithms. Unfortunately, many developers took this a little too far and essentially bring these cards to their knees. This was a decision on their part, aiming more towards eye-candy and hype than providing a “usable” gameplay experience on the new hardware. We knew this would pose a problem if we took the new features too far and decided to concentrate our efforts on a few key points:

• Restructure our rendering engine so it can properly handle DX9 and DX10. We are essentially thinking forward so we can make future releases even better.
• Take advantage of the new hardware to improve performance. We do take advantage of this under DX10 to improve our batching and our handling of textures/materials, hence the ~20% performance increase.
• Add visual eye-candy in areas where we can control the cost and get the best improvements considering the constrained amount of time we had.

This being said, this is why we are now calling SP2/Acceleration a DX10 preview. Visuals should go through SIGNIFICANT improvements in the next release.

The second part comes from this “mockup DX10 screenshot” that was released a while back… As Phil mentioned, this was a really big mistake on our part. The initial intent was for our artists to express themselves and give a visual representation of what a DX10 version of Flight Simulator should look like (and it did serve as a template when deciding which items we should be focusing on). However, I doubt this mockup was ever intended to be a “promise of what FSX DX10 will look like”. We did try to get as close as possible but due to various factors including hardware delays and re-architecture work we had not predicted, there was no way we could meet the expectations in this mockup.

So where are the differences? Well as mentioned in a previous post, the changes we made that affect the visual look of FSX are mainly concentrated in the lighting (real High-Dynamic Range lighting versus the fake bloom we were using), improved shadowing on the aircraft (higher resolution on the exterior and enabled on the interior) and water (it does not dynamically move, but the shader was significantly improved and includes some new features such as whitecaps). Single screenshots may not do justice to the new features. So as I start discussing some of the new features (as I have already done with the VC self shadowing), I will attempt to provide screen captures and videos which does a better job at demonstrating the before-and-after…

That is actually pretty cool considering a ~4million viewer base. :)

http://www.penny-arcade.com/

One of the DirectX 10 additions to FSX SP2/Acceleration is the use of self shadowing within the aircraft VCs. For the VC, we use shadowmapping, in a similar way that it is used for the external airfraft self shadowing. This could have technically also have been implemented on DX9 but we made the decision to keep this a DX10 only feature mainly for performance reasons.

Note: This feature will only appear for models that are properly built for this feature so will only work with updated FSX and Acceleration models out of the box. Third party models will need to be updated to take advantage of this feature, which mainly involves setting a new flag in the model and re-exporting. The reason for this choice is that shadow mapping does require a model to be "visually closed" when looked at from the outside. However, most of the time this is not the case as some material may not be properly double-sided or pieces of geometry may be leaving holes where there should not be any. Think of it this way, any holes when looking at the VC model from the outside is essentially a point where the light will shine through from the shadow map, leading to incorrect shadowing. We decided it made more sense to have the feature off by default unless someone explicitly marks the VC model as being "shadow map ready".

Below is a little video capture of the feature in action. It is mid-resolution to keep size and bandwidth reasonable but still shows off the feature fairly well and gives yo uan idea what to expect.

You can also download the video here: fsx_dx10_vcshadow.wmv (4.05 mb)

Now that the Acceleration expansion pack and FSX SP2 have finally RTM'ed, I can start discussing some of the specifics relating to the changes and improvements made to both of these. I know this has already been covered in other blog posts but for this post I wanted to start with an overview of the upcoming changes. Of course, since I am one of the graphics engineers on the project, my future posts will focus mostly on the graphical improvements and also improvements and changes which are related to the DirectX 10 support introduced by SP2. Before I start, I wanted to note that we purposefuly RTM'ed on the expansion pack and SP2 at the same time so that the Acceleration Pack does also contain (and takes advantage) of all the bug fixes as well as performance and graphical improvements.

As Phil Taylor mentioned on his blog:

Acceleration Pack looks really good, and for the $30 US list price there is a lot of value with 3 aircraft (F-18 jet, P-51 racer, EH101 helo), along with 30+ missions and several new “sim” features like a functional carrier, slingloads and hoists for the helo, as well as the multiplayer racing experience. And I am probably forgetting features. There is quite a bit of value there. Acceleration will be available in late October. FSX-SP2 will be available sometime after Acceleration Pack and before Christmas. Please note both SP2 and Acceleration Pack will require FSX-SP1 to be installed. As I have previously stated, SP2 will include DX9 fixes as well as DX10 support. So with the release of SP2, Aces will have fulfilled its commitment to 2 updates for FSX RTM customers in 2007.

I want to make clear two important details about the DX10 part of Acceleration and SP2:

1) From a feature perspective, we do not match the magic screenies item-for-item because those screenies ignored an important visual element—the aircraft. We added virtual cockpit shadows to the work list because this feature further enhances the immersion. Of course, we also faced schedule and other constraints.

2) We are not promising runtime backwards compatibility in the current DX10 code path now or in the future. This is for two reasons:

a)The first is to send a message that we are going to change the backwards compatibility story moving forwards.

b)The second is practical, in that continuing to provide the backwards compatibility we do is a huge drag on forward progress. Spending time on 4 or more code paths (FSX DX10, FSX DX9, FS2004, pre-FS2004) costs us time that could be spent polishing the existing features, working on resource management to fully eliminate out of memory errors, and working on performance. We have to change that balance and in the DX10 preview you can see the first notice of that. Yes, we know we have to address some features that are not possible using the FSX SDK in future SDKs so that 3rd party developers are enabled and do not depend on these old techniques and we accept that. Because of these two issues, we are labeling the DX10 support a “preview” in the UI. We expect it will add value; but we are not expecting the DX10 path to replace the DX9 path as the primary experience in FSX and expect third parties to author to the DX9 path in the large. And yes most add-ons should continue to work in the DX9 code path in Acceleration/SP2, as long as they don’t depend on the old BGL compatibility path. An example that no longer works is the B-307 Stratoliner, it uses a decal alpha technique that we didn’t get re-enabled in either DX9 or DX10 after the re-plumbing work involved with SP2.

 I know some are going to be disappointed, and some disappointment is reasonable. I will be the first to state that Aces releasing the magic screenies was flat out a mistake; but us not matching that level of “vision” ( and that is what the magic screenies were ) is not a cause for a flame war against Aces or DX10. I should note, for instance, that the DX10 code path performs better under load than the DX9 code path, and this means the DX10 features are more useable. And DX10 does look better, both in the cockpit and in the world.

So what are the overall changes with SP2? Below is a breakdown of the enhancement and fixes which can be found for SP2 when running on either DX9 or DX10... 

FSX SP2-DX9  

Here is a list of what is in SP2 from a “global install perspective” and not just on Vista when DX10 is active:

Fixes and Features Core and Graphics

1) 8-core bug fix

2) 3G enabling FSX and Autogen memory use optimization

3) Exterior shadow quality improvements

4) Optimization of terrain IO for photo-scenery and “scenery load out of the zone” fixes to help reduce blurries

5) More batching of Autogen. This will help in areas where a lot of custom objects of the same material are authored and complements the SP1 batching work.

6) 737 and A321 night/taxi light fix with new models

7) Raindrops in the 2D cockpit

Audio, International, UI

8) Audio fix for soundcard/usb to speakers/headphones on Vista

9) Various internationalization fixes

10) Saving undocked panels

11) UI fix for flight list to be alpha-sorted when "Title" is clicked Multiplayer

12) Multiplayer compatibility with XPack for free-flight. With all the changes in Acceleration, SP1 is not free-flight compatible. SP2 addresses that. 

13) Multiplayer fixes for

a) when using DIRECT CONNECT, FSX now remembers the last IP used

b) COM1 shared cockpit sync  

FSX-SP2 DX10 

The features we do have are:

1) VC shadows

2) HDR Bloom

3) Water enhancements

4) Efficiency improvements via more Autogen batching, more efficient shaders, and a more efficient method of generating bloom.

Over my next set of posts, I will start covering some of the graphical specifics and go into more details. But for now, this should give a good idea of "things to come".