PTaylor's WebLog : FSX releases

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

Phil Taylor — Fri, 13 Jul 2007 23:21:00 GMT

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 2^nd 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 1^st 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. J.

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.

FSX SP1: The blog posts

Phil Taylor — Wed, 04 Jul 2007 02:52:00 GMT

We have collected the set of blog posts I created on release of SP1, and turned them into an article on FSInsider, here http://www.fsinsider.com/tips/Pages/SP1HowtoPrepareforSP1andWhatYouGetWhenYouInstallIt.aspx, that makes for a little easier reading.

Summer is here, and so is the start of info about FSX-DX10

Phil Taylor — Thu, 21 Jun 2007 21:22:00 GMT

So it’s the first day of summer! As part of the celebration, I wanted to talk about and show progress on FSX-DX10.

First, though, let’s talk what I can show and when, as well as requirements for FSX-DX10.

I am not here to talk features. Not yet anyways. I am going to show progress on bringing the engine up on the DX10 pipeline before I talk features. So there are going to be 2 to 3 posts on progress before talking to FSX-DX10 specific features. Expect those every 2-3 weeks until mid-August or so, when I can take our famous screenshots, deconstruct them, and talk to features. Ok?

Now, what does FSX-DX10 require? First - Vista, a DX10 graphics card, and a DX10 driver. Second - FSX and SP1. Yes, SP1is a pre-req. More on that in a later post.

On to where we are with FSX-DX10.

We have all FSX geometry going thru the DX10 geometry pipeline. We have the entire child view/window system up, including docked and undocked windows. We have multimon working in windowed mode, but not fullscreen yet.

So what does that mean? Two things:

1)The device and view infrastructure is up and functional, we just need to finish it off with the fullscreen support. FSX with its view and multimon support is *the poster child* for multimon so that’s a key piece of infrastructure and non trivial. Early DX10 SDKs had no multimon sample code, so digging for information on how to do multimon in DX10 was hard and it is very good that part of the port is largely past us.

2)The geometry pipeline is up and functional; including loading vertex data, packaging vertex data into vertex buffers and index buffers, and submitting Draw calls. That is another key piece of infrastructure.

Here are some screenshots that show pushing geometry thru the pipeline in wireframe:

The World

Seattle and the Space Needle

Chicago and Meigs Field

Here is a screenshot showing multiview:

Multiview

And here is a screenshot showing multiview and multimon:

Multimon

So how did we get here so fast, just 5 weeks after SP1? We had help :-). We had one developer work on DX10 in the background while the rest of the team was engaged on SP1. He was the newest member of the Graphics and Terrain team, so this was his learning and trial by fire. He did all of the device, view, and multimon infrastructure code. And because he was in "learn-mode" and we had good coverage already for SP1 tasks this seemed like a smart deployment of resources. The progress so far bears out that call.

So what remains?

Quite a bit. We still have all the pixel pipeline work to get parity with DX9, and then the feature work. So the next progress report will be about the pixel pipeline. In 2-3 weeks you can expect another progress report. And at least one progress report past that before I talk features, maybe two.

So with all that, let me state that we are still on track for a Fall 2007 delivery of FSX-DX10.

FSX SP1:Beta3 posted

Phil Taylor — Thu, 26 Apr 2007 08:52:00 GMT

We just posted SP1 Beta3 to the beta testers.

We had a couple extra 3rd party bugs that needed to be fixed ( animated parts, mouse rects on the panels, lighting ) that we needed to fix and in fixing the stutters with the first round of threading code we lost some perf and had another bad bug lurking in there. And we identified an issue with 3 AI aircraft, 1 of which is fixed in Beta3 - if that aircraft passes muster in Beta3 we will fix the other 2.

We hope Beta3 shows these all as fixed. That does mean we have lost April for SP1. So we are into May now.

As far as how long it’s taken us, it has been longer than we thought and would have liked. Back in January, we clearly thought we had time in front of us. Just not as much as it has taken. We did hope the multi-core work would be done a good 6 weeks before it was. And the beta tests, while valuable, have added their fair share of the "extra" time. We have found and fixed a couple extra 3rd party bugs that we think are going to be of good benefit to the community because of that time investment.

So that was time well spent. As was the performance and thread bake time.

It is what it is; we are trying to get it right. That does take time. And we believe the result will show that care and attention to detail.

3rd party complications due to multiple FSX releases?

Phil Taylor — Sun, 04 Mar 2007 23:35:00 GMT

Multiple times a concern has come up that our release plan unduly complicates the 3^rd party developer’s lives and they now have support issues across multiple platforms. I have replied at least once, but instead of my posts getting buried out there in numerous threads, I will blog about this.

I don’t understand this concern.

All of this year's releases are essentially RTM in terms of features exposed in the SDK, at least so far.

So FSX is a single target unless the 3^rd party takes a dependency on a particular piece of content we authored.

Let’s remember that as we then walk thru the releases and their impact on 3^rd party development.

SP1 adds fixes. And is detectable by a 3rd parties setup. So while I can see a 3rd party wanting to test for the version number ( probably to guarantee the better performance of SP1 ) and popping a dialog to inform about lack of SP1 in the setup – how else does this release impact 3^rd parties? Maybe a little setup work, but I can’t see a content authoring issue due to this release except for one specific piece of content, see Note 1.

DX10 adds the new DX interface support. DX10 will require SP1, but that is our Setup authoring work. There is currently no DX10 specific content authoring in the SDK. As long as we keep it that way - how does this release impact 3^rd parties? Even if we did change the SDK then a 3rd party could decide to target DX9 only and not have to worry about this release at all, setup or content authoring. We do have an obligation to discuss on the beta forums any FSX SDK changes driven by DX10 features so we can front-end load the community’s knowledge base. And we won’t make a change or addition without there being a clear benefit.

XPack adds new content, true. It will also contain SP1 and DX10 which should actually make XPack better for 3^rd party developers. So unless a 3rd party targets the specific new content here - then does this release impact 3^rd parties? Especially if the 3rd party ships ahead of XPack - all things being equal and the add-on follows the rules then there should be no issue here. The XPack team are the ones to talk to their plans in more detail but I know they also take the relationship with the 3^rd party community seriously.

Now, true it is possible for a add-on to take a specific content dependency and to have to care. But that should be a conscious decision and is not something forced simply by our release schedule.

So the most likely scenario is the 3rd party has performance concerns and wants to detect SP1’s presence or absence and perform some UI interaction when there is no SP1. So there is likely a little more work for everyone at Setup time. But not a horrendous amount.

Or am I missing something here? A dialog is welcomed.

Note 1: One performance fix we are evaluating pertains to our authoring and rendering trees differently. This does affect vegetation.bgl, but is controllable by the .cfg file. We are working to make sure excellent add-ons like TreesX are not impacted but we have to go thru the test pass to make sure of this. The beta forums will be the proper place to discuss this issue in depth. Stay tuned late next week for more!

The PC Industry, Multicore, and FSX ( with a little DX10 thrown in for good measure )

Phil Taylor — Wed, 14 Feb 2007 22:08:00 GMT

This is a recap of an AVSim.com post, that I wanted to capture here.

I'd like to take the time to address 2 areas that come up often:

1)FSX designing for multicore
2)FSX designing for DX10

1)FSX designing for multicore

As I stated in a previous post last year, the switch from Ghz to Multicore took most everyone by surprise in the entire industry. Reading a little history and thinking it through is informative.

All during 2004, when FSX was still in design stage and could be easily changed, the roadmaps were still predominantly Ghz based and multicore was a "variant".

Take AnandTech, a highly regarded site and look at their reviews throughout 2004.

Q1 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.html?i=1948
no mention of cores

Q3 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2233
cores are a "variant", as in "it would make sense if the FX-57 were to come with a dual core variant"

Q4 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2303
It is only at the end of Dec 2004, with this review, that cores have been elevated somewhat in importance but note Ghz hasnt been deprecated hence quotes like this:
"There are other areas besides the high-end multi-core arena, and we haven't seen the end of increasing clock speeds yet"

Now move to 2005, and lets look at Toms' Hardware
http://www.tomshardware.com/2005/04/05/the_pentium_d/page2.html
and this review has a section "Sorry Guys, Clock Speed Does Matter" so the fact that the technology pony had jumped the tracks from Ghz to cores hadnt sunk it, even at sites whose job it was to keep up with this.

It isnt until 2006 that it has really sunk in and permeated the community. Mainstream sites have picked it up, like http://www.informationweek.com/shared/printableArticleSrc.jhtml?articleID=175802849.

Still enthusiast sites like http://www.guru3d.com/newsitem.php?id=3620 mention:
"Now through to the end of 2006, we will see Conroe taking up roughly 20% of Intel's shipments by then end of the year while the Pentium D processor will remain the largest bulk of Intel's desktop shipments."

So from a volume standpoint multicore wasnt seen as a majority in 2006 thru the entire 1st quarter and March IDF.

So while its easy to say "why didnt you see this coming" I think when you look at the available data it should be pretty clear that it wasn't that easy to see it coming.

Given where FSX was, by end of 2005 and early 2006, when this data started to sink in the project was so far past design the team couldnt react to rearchitect within the existing plan. It wasn't really an option to ditch the existing plan.

Even with that, we do have some multicore usage today and are working to get more. We reacted as we could within the original plan. So be careful with comments like "not once did they think" as that just isnt true.

2)FSX designing for DX10

With the last slip in Vista, combined with the associated slip in DX10 hw, the new DX10 schedule put it outside of the FSX ship timeframe. We didnt get DX10 prototype hardware until after the product was in manufacturing. Well after.

DX10 is a fairly major rewrite. And without hw on a title like FSX it is a major challenge to make forward progress. So we didnt think it wise to wait and shipped on DX9. We did think about what could be done with DX10 and we do have a good plan. And many of our existing features that challenge the DX9 pipeline should get better in DX10.

So we are really looking at what can be done with cool new features like texture arrays, large constant buffers for shaders, long shaders, low overhead API calls, better small batch Draw call behavior, etc. I have promised to go thru the "artistic impression" screenshots we have released and detail what features we see in them. We need to ship SP1 first and get back on to DX10 so I can talk to what features will actually be in the DX10 update and not a wish list. So give me time on that discussion.

In conclusion, given the jump from FS2004 to FSX, I think people should be a bit more careful in making accusations about the dev team and its thought process. We were most decidedly not sitting still. And its entirely too easy to play Monday-morning quarterback.

FSX Progress Update - SP1 and DX10

Phil Taylor — Thu, 01 Feb 2007 00:52:00 GMT

Its time for another update on FSX Progress. This is largely similar to what I posted on Avsim.com.

SP1

We are working thru the set of tasks we identified for SP1, are getting closer to closure and a final test pass, and should have more to say as far as details in the next couple of weeks.

The only things I can say is:
a)we are not toning down the experience and
b)we are aiming at a targetted set of perf and content fixes.

DX10

In terms of DX10, we have continued to make progress albeit slow. So DX10 will be after SP1. How far after SP1 remains to be seen, but its not a matter of weeks after since we still have serious feature work to do. Once SP1 ships and we get fully into DX10 development and a sense of velocity then I can start to talk to DX10 timeframes. One thing I will commit to doing soon after SP1 ships is walking the community thru the FSX "magic screenies" for DX10 and explaing what features Aces sees in those. If anyone saw the FSX presentation at the nVidia 8800 launch, I did just that so repeating it here is a good thing. Its just a matter of time, as in when I find the time :-).

Fair enough?