Friday the 13th is here, and so is the 2nd FSX-DX10 progress report

With this blog post, I have likely run out of snarky dates to make a post on. Ides of August anyone? J. So on with the show

First, this is not the FSX-DX10 feature discussion. Nor is this the “what will be in the DX10 release for DX9 users” discussion. Why not you ask? Because that work is still in flight. And we could still find something that would necessitate us dropping a feature or fix before the final FSX-DX10 release. My current plan is to make a feature disclosure post in public in mid-August when we should know with much more certainty what DX10 features will ship and what fixes we can fit in around the edges.

How could it be possible that we don’t know what we are doing? Well, that’s a bit of a strong interpretation. Of course we have a plan. But like the old saying “no battle plan survives contact with the enemy”; software project management has the same issue. Events happen and require adjustments to the plan. Some are minor, and are akin to tacking a sailing ship down a course. Some are major and are equivalent to having sails blow out and losing the lead. You just cannot predict; and with that being true I tend to remain conservative in what I say to not build any false expectations.

So what can I say? I can talk to the general organization of the project so you get a sense of what needs to be done and where we are. And a 2nd set of screenshots.

Practically speaking, we broke the work into 4 phases:
1)Device and Infrastructure bring-up
2)Geometry Pipeline bring-up
3)Pixel Pipeline bring-up to "rough DX9-level comparability"
4)DX10-specific feature work.

The 1st 2 phases had to happen before the last 2 phases could even start. And the 1st public post on FSX-DX10, roughly 3 weeks ago, showed we had essentially finished those phases.

The last 2 phases, though, can be done somewhat in parallel once enough of the Pixel Pipeline is operational for a specific feature. Because we are doing things in parallel; while that does provide the opportunity to speed up the work - it also introduces risk that integration of the features together will show something unexpected. So that is how we could have a feature that looks pretty good now, but might not make it later. And why I want to remain conservative and not show my feature cards yet.

Why does it work that way? We have a tight timeframe to make our Fall release schedule and move off onto the next set of projects. And we dont want to mis-set expectations.

So now on to what I can report at this time.

We have some progress on the Pixel Pipeline. Okay, okay, maybe that was too obvious. J.

Here is some more detail.

The first thing we did was bring up what we call the “fallback material” which gave us a solid color for every triangle, here.

So what is next? Well, textures, materials/shaders, and effects. D3D10 changed the texture formats, so we have to write conversion code to swizzle the textures on the fly. That means each and every texture format requires code to be touched. Except for DTXn textures. So that was the first to be brought up, what we call the basemap, here. So you can start to see some definition in the world, but lots of objects are still black rectangles.

Is that it? No, we actually have swizzled texture formats working; but they still require material/shader and effect support to reach DX9-level visuals and thus appear a bit flat. Here is a shot off the edge of the Trike, showing ground textures, tree textures, the sky, and gauges. And a VC shot here. Note a couple of things that highlight the lack of shader and effect support. The edges of the rectangles around the tree textures show black – lack of alpha material support for transparency. The sky shows the stars as black dots, again lack of material/shader support. And all the cockpit materials aren’t working as the lack of glare across the bar and the lack of alpha in the windscreen shows. Here is another cockpit shot, and it looks similarly flat; an indicator the textures are there but not the shaders/materials.

No more? Just a final shot in multi-mon mode, to show the value of the infrastructure bring-up.

Unimpressive looking overall in general, unless you map it to the plan I outlined above with its phases and use that to gauge our progress. So we are making good, steady progress since we came off SP1 roughly 2 months ago.

To set expectations, I may or may not make one more interim screenshot post like this before talking features. The current plan is to have that discussion in mid-August, but that discussion could always slip to early September as there is a lot more to be done before any feature is "final" and "committed".

I hope that makes sense. And now, perhaps, the pacing of progress reports make sense too.

Sorry to be long-winded. I hope this is useful.

Comments (10)
  1. NickN says:


    The acceleration pack and DX10 are due out about the same time. I know this blog entry is specific to DX10 however with that update it has been said that other areas may also be addressed as time and the project sees fit, and that it may be renamed SP2, possibly. In that, there is a feature that appears to not function in FSX as it did in FS9 even though the settings are the same in the configuration of the program.

    I would like to inquire about crash detection features in FSX. It would appear they have been changed significantly. The sim no longer detects when one aircraft comes in contact with another. This in my opinion removes a realism that should not have been removed.

    In example, and I am going to copy part of a statement I made at one of the sim forums and upgrade it for this inquiry:


    I have had the pleasure of having ATC clear me for final at a socked in airport at night when a AI plane was on the runway and I could not see it until I was practically committed. That is an experience which without the penalty, makes the accomplishment of getting out of the situation worthless simply because you cant tell if you made contact with the other plane or not in a evasive so you have no way of knowing if your reflexes, decisions and performance was good.

    With the addition of the ‘races’ and other multi-aircraft additions, and the acceleration pack, that feature not being enabled just blew it for me. Why fly a race when I can pass right through my competition to take the lead?


    Note that I and many others have removed the AI traffic and replaced it with much more frame rate friendly aircraft. They all appear to have correct contact points and in FS9 these aircraft were detected in a crash or ‘clip’ situation just fine. The settings in FSX are identical to FS9 in that respect and it has been tested to see if changing those settings may net a different result, it doesn’t.

    I have no desire to crash into buildings or other planes on purpose but there is a significant loss in realism when close calls come up in both taxi and flight without that feature working.

    I can not see how a Red Bull race between two aircraft could be any fun or challenging if a mistake in close nit race flying does not bring on a penalty. Same with the close calls at the airports on the taxiway and ruways. It makes no sense.

    Could you please comment on this issue, and, if crash detection with other aircraft has been removed, why, and, if you may be considering restoring the feature withthe next service pack?

    Thank You


  2. Phil Taylor says:


    We have basic crashboxes defined on objects, but you have to turn realism on and its off by default. So when realism is on you should get this basic crash behavior.

    There is some limited aircraft-aircraft collision too, but there is no real "damage" to the aircraft.

    This work is beyond what could be accomplished in a service pack.

  3. NickN says:

    Hi Phil

    Thanks for getting back to me on this. Realism slider is set to 100% and all checkboxes are correctly enabled. I guess the biggest concern is the reaction to contact and not so much seeing fire and flames. I think it’s important that the aircraft being flown at the very least respond to the impact type and not just a STOP. At the same time my self and a few others are not seeing any response by the sim to contact with AI, at all.

    It is possible the AI we are using in missing needed code, as you mentioned, “crash boxes”. Is this something new with FSX? I need to get into the SDKs and I have not had time recently but will do so soon.

    In FS9 the resulting impact appeared to be calculated by the impact force on a contact point. Close to the max and there was damage but not enough to invoke the full stop crash bar. We are not seeing this at all in FSX.

    If perhaps it is the replacement AI and lack of coding in it for FSX, then I can understand what is happening. I will need to test the default AI and see how it responds to the aircraft being flow. I should not be able to pass right through a plane in front of me on the taxiway. 🙂

  4. Phil Taylor says:


    here is a post I made on, at

    What I found:

    Your settings must be:

    Detect Crashes and Damage, Radio Button on.
    Aircraft stress causes Damage, checked.
    Allow collisions with other aircraft: checked ( you had this unchecked )
    Flight Model Crash tolerance – I had it all the way to the right.

    This must be local to your settings, as I just tested this with the Trike at SEAATAC for the following 6 scenarios:

    Scenario                       Effect   

    Trike Hitting Ground:          Crash
    Trike Hitting Radio Tower:   Crash
    Trike hitting ATC Tower:      Crash  
    Trike hitting parked aircraft: Crash
    Trike hitting airport vehicle:  Crash
    Trike overspeed:                 Crash

    And I correctly crashed in all of these.

    The ground crash did have an animation for it, none of the other crashes appear to have an animation defined. Thats just how we modeled it.

    So anywhere we have crash boxes defined, when you use the appropriate realism settings you will get crashes. 

    The damage modeling is minimal by intent.  I believe a 3rd party could do additional animations for the other crash types, but I would have to double check that.

    Note, this is all off by default, you have to turn it on.

  5. NickN says:

    That was actually someone else who brought the subject up. I am using replacement AI traffic like him and see the same results as he does. I did try changing the settings as it was suggested by a few others in the thread but saw no change in how AI and the aircraft being flown interact. So at this point I have to assume it is our AI installs that may be causing the lack of contact response we see. Being FS9 would work the same with AI add-ons I assumed (dangerous word) it would work the same in FSX.

    Thanks for responding to this!  


  6. Phil Taylor says:

    If its not stock content, I have no idea.

  7. NickN says:

    It is a very popular practice to replace the default AI aircraft with 3rd party in order to run a much higher volume of traffic and have realistic flight schedules installed, without the hit to performance.

    Since the subject may come up in the future as more 3rd party packages are released and more people may replace their traffic, this issue may be noticed and it’s good that we know for sure it is not anything directly related to FSX.

    As busy with the project as you are, it was kind of you to take the time in looking at this subject.

  8. NickN says:

    Hi Phil

    I have been enjoying some very fun flights in FSX. You guys did a wonderful job on the Beaver and it is by far one of the most impressive aircraft for flight dynamics and visual appeal I have had the pleasure of flying in simulation.

    I have also been flying with light bloom enable under bush conditions where using that feature with the right hardware can be done. The results are spectacular and another awesome edition to the software. It brings out an entire new level of visual realism and enjoyment.

    My question is about light bloom and the upcoming DX10 enhancements. I was curious if you and the team may be discussing any changes in that area for the upcoming patch. The reason I ask is because the bloom, at least on my hardware, tends to be a bit excessive depending on the camera angle and I was wondering if there may be a way to control the amount of bloom being rendered. Right now I find that using the zoom feature helps control the scale and intensity however the aircraft lights and other areas such as the sun and airport lighting still tend to display a much larger bloom than my taste prefers.

    I am not a graphics engineer and have limited experience in coding such things however if there was a way to allow the user to control bloom scale and intensity by a slider, in my option that would be a very nice feature which would take into consideration the users taste.

    Not understanding how it works I don’t know if having the ability to control the bloom scale and intensity would also reduce the hit to system resources, however, if it would do that, it also opens the door for those who may not be fortunate enough to afford expensive components to have a touch of bloom and some of the visual benefits that may provide.

    Of course if enabling the feature at all, no matter what the level or intensity it may be displayed, requires the same amount of shader passes and resulting system hit would be the same then that would not be of benefit, but, none the less having the ability to control that presents the user with adjusting their environment to personal preference.

    Would that be possible to do?


  9. It is time to update everyone on the progress we have made on the FSX-SP2(DX10) release. First, we have

Comments are closed.

Skip to main content