LM are currently the ONLY folks that could do the move to 64bit but they have indicated V2.0 is all about DX11 and other fixes - no 64bit.

 

This makes the most sense. I am glad they are doing it that way. You have to remove bottlenecks and problems first. Its like the 64bit being the 64 lane highway but to get on the highway is a road full of potholes, cracks, and is only 4 lanes with a whole bunch of cars trying to get on at the same time. So eventually 64 bit will come. Just let it be known that Jim Skorna will be permanently banned from it because he is against it altogether.

 

 

However, there is a community of software engineers who are also FS enthusiasts that would be more than willing to move FSX to 64bit using their limited spare time ... IF access were provided to the source code via TFS (Team Foundation Server - Visual Studio source code version control tool).  A large community of volunteer developers could probably get the job done in < 1 year vs. the small team at LM. 

 

Im confused about one thing, though. There is too many reports of who has the source code and if its leased or owned. Im guessing that LM did mention that it is in future plans, so they must have access to it one way or another. So if there is a group of SW engineers to help out, you would think this is a no brainer for them to have help on this. Particularly if it cuts the time down, and there is cost savings to doing it completely internally and for much longer. I hope it works out for you guys! And I bet if it is very doable once you have a look at the whole thing, the FSX community would pitch in. 

I don't understand how one could "lease" source code unless they were NOT allowed to change it and it's for "view only" purposes?  (which is not the case with LM)

 

 

In 2009 Lockheed Martin announced that they had negotiated with Microsoft to purchase the intellectual property (including source code) for the Microsoft ESP product. Microsoft ESP is the commercial-use version of "Flight Simulator X SP2". On May 17, 2010,^[12] Lockheed announced that the new product based upon the ESP source code would be called "Prepar3D" (pronounced "Prepared").

 

LM have already changed the code ... verified by looking in my P3D folder on v1.4 ... so not sure where or who you got the "lease" idea from? 

 

There could be plenty of reason why LM don't want "volunteer" help (financial, legal, political, military secrets, variance in developer expertise, etc. etc.) -- but again, with TFS they can make available a separate image of source code that would not impact their current development path and/or any of their own proprietary code.  That image could be from the original "Flight Simulator X SP2" that doesn't include any of LM's work up to current.

 

I obviously can't determine how many developers would offer up their free time to work on a 64bit FSX (and other fixes), but I suspect A LOT of developers would LOVE the opportunity to dig into FSX SP2 source code (even those that have walked away from FSX).  But it's not trivial, all developers working on it would need background checks, qualification checks, and more to ensure the work isn't for personal gain and/or malicious activity ... so not really 100% "open source" and there is a central code depository (aka TFS) with restricted access.

 

It's an entertaining idea, but I doubt it'll ever happen.

There could be plenty of reason why LM don't want "volunteer" help (financial, legal, political, military secrets, variance in developer expertise, etc. etc.) -- but again, with TFS they can make available a separate image of source code that would not impact their current development path and/or any of their own proprietary code. That image could be from the original "Flight Simulator X SP2" that doesn't include any of LM's work up to current.

 

Lockheed Martin licensed ESP, not FSX, so it couldn't start with Flight Simulator X SP2 which Microsoft still owns and is still selling.

 

Although none of us know what's in the Lockheed Martin/Microsoft agreement, the facts suggest that it precludes Lockheed Martin from offering anything for  personal/consumer entertainment. purposes.

 

Also, I doubt Lockheed Martin has any interest in such a development in any event.

Just like DX10 saves on memory usage in FSX, couldn't moving to DX11 in P3D 2.0 cut memory usage in a similar manner? I wouldn't anticipate enormous gains but DX10 saves a few 100 megabytes, hopefully Lockheed has optimized further beyond that.

FSX memory problems often seem to occur well into a flight. That suggests that FSX is not releasing memory when it should.  In this case going to 64 bit is merely treating the symptoms not the cause.

 

Changing to DirectX11 requires a major re-write of the whole graphics package which should provide the opportunity to release memory appropriately.

 

 

Lockheed Martin licensed ESP, not FSX, so it couldn't start with Flight Simulator X SP2

 

Where did you here that?  It contradicts with other sources (see my quote above).

 

The ESP is at least SP1 (Phil Taylor mention getting the ESP with SP1 done) with the copy protection code removed and maybe a few other files modified to remove any "Logos" used that were not licensed to Microsoft for use in the ESP ... but it does appear to use SP2 specific files that are different in SP1 such as  ShadersHLSL\Terrain\Terrain.fxh.  But whether it's based on SP1 or SP2 doesn't really matter ... it's FSX code base.

 

I don't understand how you know that DX11 will fix the memory allocation issues?  FSX doesn't just allocation memory for GPU specific tasks, it allocates memory for all kinds of processing from ATC to weather to flight physics and much more.  I'm not disagreeing they exists, but I am not seeing how you know they all related to graphics processing?

 

It's better to NOT think of DX11 as a graphics package, code simply elects to use the API (DLLs) or it doesn't ... better to think of it as a series of function calls (extensions) that are only available in a particular DLL set (DX11).  P3D are using SlimDX which is a way to put a wrapper around DX calls and use them in a .NET Framework based application ... again, you can see SlimDX in P3D folder and if you do a dependency walker on the executable you can see SlimDX loading.

 

 

 

Just like DX10 saves on memory usage in FSX, couldn't moving to DX11 in P3D 2.0 cut memory usage in a similar manner?

 

I'm almost certain DX10 in FSX helps with memory allocation because it uses a DX10 specific feature called geometric instancing (think AutoGen objects) ... here is an excellent read on Instancing in DX10 http://software.intel.com/en-us/articles/rendering-grass-with-instancing-in-directx-10 key quote from that article:

 

 

Geometry instancing allows the reuse of geometry when drawing multiple similar objects in a scene. The common data is stored into a vertex buffer and the differentiating parameters like position, color are stored in a separate vertex (instance) buffer. The hardware uses the vertex and instance buffer to render unique instances of the models.

The use of Geometry instancing API's helps factor common data from the unique data (flyweight design pattern) and thus lowers memory utilization & bandwidth. The vertex buffer can stay resident on the graphics memory and the instance buffer can be updated more frequently if needed, thereby giving us the performance and the flexibility needed.

 

This was not really available in DX9, accelerated support came in DX10 and that support continues on to DX11 ... DX11 does NOT do instancing any better (faster or more efficient) than DX10.   DX11 brings tessellation, multithreaded rendering, compute shaders that can be used for something other than graphics (such as physics), and better texture compression.

 

Rob.

 

 

LM have already changed the code ... verified by looking in my P3D folder on v1.4 ... so not sure where or who you got the "lease" idea from? 

 

Sorry, I used poor choice of words. Lease should be licensed which was answered and addressed. Thanks

Where did you here that? It contradicts with other sources (see my quote above).

 

Microsoft's own press release:

 

ORLANDO, Fla. — Nov. 30, 2009 — Lockheed Martin (NYSE: LMT) and Microsoft Corp. entered into an intellectual property (IP) licensing agreement that allows Lockheed Martin to further develop the Microsoft ESP PC-based visual simulation software platform to better train warfighters for battle.

 

 

Microsoft ESP technology allows users to operate realistic vehicle models that incorporate real-world physics to enhance realism, such as in the interior and instrumentation of a Boeing 747-400 shown here.

 

The agreement provides Lockheed Martin with access to the ESP technology portfolio enabling the company to build cost-effective simulation solutions for customized training for its worldwide customers. Lockheed Martin’s software development teams will extend the current capabilities of ESP to enable a whole new suite of innovative ESP-based solutions that will evolve beyond flight training to include ground and civil agency applications.

 

http://www.microsoft.com/en-us/news/press/2009/nov09/11-30warfightertrainingpr.aspx

 

I don't understand how you know that DX11 will fix the memory allocation issues? FSX doesn't just allocation memory for GPU specific tasks, it allocates memory for all kinds of processing from ATC to weather to flight physics and much more. I'm not disagreeing they exists, but I am not seeing how you know they all related to graphics processing?

 

That's not the case. DirectX 11 does handle memory. Where does the memory come from for crate.dds in the following snippet?  DirectX11 acquires it and releases it.

 

// Declare pointer to shader resource view
ID3D11ShaderResourceView* MyShaderResourceView = NULL;
.
. 
// Create shader resource view from .dds file
Result = D3DX11CreateShaderResourceViewFromFile(MyD3DDevice, L"Crate.dds", NULL, NULL, &MyShaderResourceView, NULL);
.
.
// Assign it to the pixel shader pipeline stage
MyDeviceContext->PSSetShaderResources(0, 1, &MyShaderResourceView);
.
.
// Release shader resource 
MyShaderResourceView->Release();

 

 

Never say never Jim

 

I am talking about FSX, not P3D Ver whatever, which is NOT entertainment software, or XPX which is already 64 bit. I mean a piece of software that will have a FSX splash screen and be 64bit. Hasn't happened, never will.

 

 

DirectX 11 does handle memory

 

Agree, but it's by no means the ONLY process the FSX executable will allocate and de-allocate resources for ... there are many other threads/processes occurring that could be responsible for not correctly releasing resources that have nothing to do with DX/graphics.  Your initial statement suggested that DX11 is needed to release resources correctly and that's just not the case ... without profiling FSX with debug symbols and source code, there is no way we can identify all the possible areas of code that is OR is not doing memory allocations correctly, not to mention all the other aspects around contiguous memory and virtualized memory at the OS level.  We can profile the FSX.EXE and make some guesses, but that's all they are.

 

I don't see anywhere in the link or the quote's you made from Microsoft's saying ESP is not based on FSX SP1 or SP2?  It doesn't saying another about what ESP code is based on.  Phil Taylor was PM for ESP and this is from him directly: http://www.linkedin.com/in/phil3d

 

 

4) On Ship Team for Acceleration and ESP v1.0 which included FSX-SP2.

... because it uses a DX10 specific feature called geometric instancing (think AutoGen objects) ... here is an excellent read on Instancing in DX10

 

Geometry instancing allows the reuse of geometry when drawing multiple similar objects in a scene. ...

 

....This was not really available in DX9, accelerated support came in DX10 and that support continues on to DX11 ... 

 

Rob.

 

Sorry to step in but just for the sake of accuracy..

 

Geometry Instancing was and is used very well in DX9, and we have been using since just after FS9 and during the early development of FSX and FSX SP2 was coded to make better use of it, or should I say supposedly better use (I preferred the way it use to fade in and out of view) - and I believe if memory serves me that it required the Direct x 9.0C Patch as used in the installer.

 

NV white papers...

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter03.html

 

And Here

http://msdn.microsoft.com/en-us/library/windows/desktop/bb173349(v=vs.85).aspx

 

Other sources

http://timothyhkennedy.com/hardware-geometry-instancing-with-directx-9/

 

I'm also pretty sure ESP=SP2 not SP1

 

Not trying to be a smart Az, But I hope this helps, please carry on.

I'm also pretty sure ESP=SP2 not SP1

 

It better should be, because if I had just bought a commercial license for several thousand $ just to discover that the product isn't patched, it's be pretty angry.

 

 

Speaking about instancing, I still find it a bit unfair that the "BATCH_AUTOGEN2" switch is DX10 exclusive and I wonder how much of the performance difference between DX9 and DX10 can be attributed to it.

 

 

Geometry Instancing was and is used very well in DX9

 

I stand corrected ... currently SlimDX for DX10/11 usage here ... drum roll VB.NET ... oh the horror.

 

I certainly appears DX9 does indeed improve performance with geometric instancing.  However there are major differences in how DX9 and DX10/11 operate (state management) ... AMD had some warnings about porting DX9 code to DX10 and what to avoid (interesting reading but it's something I've never had to think about in terms of porting):

 

http://developer.amd.com/wordpress/media/2012/10/Harnessing%20the%20power%20of%20DX10.pdf

 

http://developer.amd.com/wordpress/media/2012/10/Ultimate%20Graphics%20Performance%20for%20DirectX%2010%20Hardware%20-%20Develop%202008.pdf and

 

http://developer.amd.com/wordpress/media/2012/10/Riguer-DX10_tips_and_tricks_for_print.pdf

 

perhaps it would be better to say "Geometry Instancing" support has been improved in DX10 ... can't confirm because I've not done a side by side compare.

 

Excuse the ignorance PigsInSpace ... former Aces developer?

 

 

 

I'm also pretty sure ESP=SP2 not SP1

 

Me too, given Phil Taylor has it listed on his resume!

 

 

 

Speaking about instancing, I still find it a bit unfair that the "BATCH_AUTOGEN2" switch is DX10 exclusive and I wonder how much of the performance difference between DX9 and DX10 can be attributed to it.

 

I did wonder what that setting in my FSX.CFG was about perhaps this is a clue from the above links:

 

 

DX10 Batch Performance

 

The truth about DX10 batch performance “Simple” porting job will not yield expected performance.

Need to use DX10 features to yield gains:

• Geometry instancing
• Intelligent usage of state objects
• Intelligent usage of constant buffers
• Texture arrays
• Render Target selection (but...)

 

Geometry Instancing

 

Great instancing support in DX10
Best way to reduce batch overhead by far
Bind additional streams containing instance data
• And/or use “System Values” to vary rendering
– SV_InstanceID, SV_PrimitiveID, SV_VertexID
Watch out for indexing too much data from CB!
• Additional vertex streams are usually preferable

 

Perhaps this is why it's DX10 only, but again, I've never done DX9 to DX10 porting.

ESP was developed on the back of FSX but they were different products sold through different channels, with different licences.

 

Microsoft licenced ESP to Lockheed Martin under an agreement that allows Lockheed Martin to develop it further but Microsoft retained FSX and still sells it.

I did wonder what that setting in my FSX.CFG was about perhaps this is a clue from the above links:

 

 

Perhaps this is why it's DX10 only, but again, I've never done DX9 to DX10 porting.

 

Hm. Sounds like it is just another "beginning of something great" then, just like the whole rest of the DX10 preview.

 

 

 

Gave DX10 another shot today. Saw lots of white AI aircraft and turned it off again. Too bad. :|