The Change to 64 Bit - What Exactly Happens?

[jabloomf1230 2,445]

What makes you think that this isn't their approach? P3d V1 was just a port of FSX and just a "proof of concept". 

[WarpD 824]

2 hours ago, jabloomf1230 said:

What makes you think that this isn't their approach? P3d V1 was just a port of FSX and just a "proof of concept". 

No, it wasn't... and no, it wasn't.

Prepar3D v1 was ESP, not FSX.  While ESP was based on FSX, there are several aspects of FSX that wasn't part of ESP at all.  There was absolutely no menu, no starting window to define a flight, etc.  Lots of things that are part of FSX were never in ESP and thus not in Prepar3D v1.  With each release of updates and versions of Prepar3D it moved further and further from ESP to now it's radically different code-wise.

It also wasn't a proof of concept, it was a necessary step because Microsoft had pulled the plug on FSX as well as ESP and Lockheed-Martin had already invested in the use of ESP.  It was a natural step forward for them to purchase the rights to create their own version of ESP.

[anden145 2,285]

58 minutes ago, WarpD said:

...

With each release of updates and versions of Prepar3D it moved further and further from ESP to now it's radically different code-wise.

...

 

I assume you mean... "With each release Prepar3D has moved further and further away from FSX"?

Prepar3D is still using ESP as engine. But Lockheed-Martin has evolved and re-developed ESP into their own version, which makes Prepar3D (again with each new major release) differ more and more from the original ESP code, which FSX is based on. Or have I missed something?

Hope that makes sense, btw... 

[JamesIceland 14]

2 hours ago, WarpD said:

No, it wasn't... and no, it wasn't.

Prepar3D v1 was ESP, not FSX.  While ESP was based on FSX, there are several aspects of FSX that wasn't part of ESP at all.  There was absolutely no menu, no starting window to define a flight, etc.  Lots of things that are part of FSX were never in ESP and thus not in Prepar3D v1.  With each release of updates and versions of Prepar3D it moved further and further from ESP to now it's radically different code-wise.

It also wasn't a proof of concept, it was a necessary step because Microsoft had pulled the plug on FSX as well as ESP and Lockheed-Martin had already invested in the use of ESP.  It was a natural step forward for them to purchase the rights to create their own version of ESP.

Am I right in saying that quite a lot of the team from Microsoft are at Lockheed Martin working on P3D?

It's been interesting to read the insights. They seem to vary from it being potentially very easy for developers to transition to a 64 bit platform to it being more difficult if they have used particular coding. That's why I was interested in the different types of add ons and what may be needed for each to work in a 64 bit environment.

Would I be wrong to guess that the most complex aircraft (e.g. PMDG, Majestic, A2A) will prove harder to port over or does it depend on how they've been coded initially? 

It sounded like scenery was easier but Pete mentions some other coding being used by some developers so again, it seems like it's going to depend on each situation. 

I'm just curious about the process that different developers may have to go through - I wonder if any have had some foresight and coded things from the outset with a 64 bit future in mind? It would seem a potentially logical thing to do I suppose, if it is indeed possible to do.

Perhaps we will get a P3D 32bit to 64bit tool similar to the Migration Tool some used when switching back in the day! I'd imagine that is highly unlikely to be work well but there are some pretty genius Flight Sim coders out there (the likes of the FSFX guys spring to mind) so who knows?!

I would imagine that LM will try to make the transition as easy as possible for developers. Orbx having announced that they will not charge for the change to v4 would indicate (to me at least) that it has perhaps been easier to get things working in v4 that it was for v3 - I remember when they spent all that time porting everything over to work in the new versions each time for free and it led to John initially saying that there would be a future charge. The fact that this has changed perhaps means very little extra work has been needed. Plus there is that "rumour" which was posted about things being in beta and add ons already working. All of this is conjecture of course. 

Good to hear any further thoughts on what may be needed for the add on developers to get things working.

[Lorby_SI 2,038]

About the programmatic addons:

This is actually not really a question of 32 vs. 64 bit. The important part is, if the API is kept the same or if it changes. If SimConnect is changed, replaced or altered significantly, every addon using it will simply cease to function. Then the addon has to be reevaluated in all details, as there is no way of knowing if that changed API will behave like the old one did. And if there are enough changes or some crucial part is behaving differently, you can go right back to implement your addon a second time from the start - and there is no guarantee that it is even possible to do what you did the first time.

Depending on what developers are prepared to invest into this very limited market, addons may be adapted - or not. If the developer is still around, that is (see AES and FSX:SE...).

An example: DTG ported FSX to 64bit and named it FlightSchool. But for whatever reason they left out SimConnect - it is not available at all, in fact there is no API whatsoever! So there is no "porting over" of programmatic addons, aircraft systems or gauges - ever.

To get a feeling about what happens if significant items are changed in a simulator platform, take a good look at the XP11 public beta. In one release LR changed some basic parameter about the engine simulation - in the process rendering every single addon airplane useless that before this was deemed compatible.

Best regards

 

 

[albar965 1,042]

10 hours ago, Pete Dowson said:

Actually that is not necessarily true. One of the techniques which can be used in scenery BGL files is resorting to Assembly Code in order to do rather clever things. I know there are several scenery designers who do this on occasion. Such code will crash in 64-bit mode -- assembly code is very different.

Add-on aircraft which use only XML gauges will probably be easily ported, but the original panel tools provided in the Microsoft SDK actually encouraged the writing of C/C++ gauges -- they are effectively DLLs just like the ones loaded by DLL.XML entries, except loaded by PANEL.CFG declarations.

I don't know much about aircraft MDL files, but I suspect that they, too, may sometimes carry machine level code.

If and when it happens it will be interesting times, that's certain! ;-)

Pete

 

Thank you for the clarification, Pete. I know they use an assembler to generate data structures. That some even use it  to generate executable code is new to me.

I also forgot about the gauge dlls which have to be recompiled.

Yes, it will be interesting. 

Alex

[JamesIceland 14]

58 minutes ago, Lorby_SI said:

About the programmatic addons:

This is actually not really a question of 32 vs. 64 bit. The important part is, if the API is kept the same or if it changes. If SimConnect is changed, replaced or altered significantly, every addon using it will simply cease to function. Then the addon has to be reevaluated in all details, as there is no way of knowing if that changed API will behave like the old one did. And if there are enough changes or some crucial part is behaving differently, you can go right back to implement your addon a second time from the start - and there is no guarantee that it is even possible to do what you did the first time.

Depending on what developers are prepared to invest into this very limited market, addons may be adapted - or not. If the developer is still around, that is (see AES and FSX:SE...).

An example: DTG ported FSX to 64bit and named it FlightSchool. But for whatever reason they left out SimConnect - it is not available at all, in fact there is no API whatsoever! So there is no "porting over" of programmatic addons, aircraft systems or gauges - ever.

To get a feeling about what happens if significant items are changed in a simulator platform, take a good look at the XP11 public beta. In one release LR changed some basic parameter about the engine simulation - in the process rendering every single addon airplane useless that before this was deemed compatible.

Best regards

 

 

That's a really interesting post, thank you - it'll come down to what LM decides to do then I guess in terms of changing things on their end. It would seem sensible for them to make minimal changes in terms of trying to ensure add on developers are minimally affected. But then this could also be an opportunity for them to shake things up totally with a fresh 2017 sim. As you say also, it is a limited market - I imagine their main target client is not an flight sim home enthusiast so any decision they will make about development will likely be reflective of that. Causing a development headache for a small 2 person team (for example) add on developer may not be a priority if NASA (or similar) are demanding certain changes/implementations.

[Lorby_SI 2,038]

28 minutes ago, JamesHongKong said:

That's a really interesting post, thank you - it'll come down to what LM decides to do then I guess in terms of changing things on their end. It would seem sensible for them to make minimal changes in terms of trying to ensure add on developers are minimally affected. But then this could also be an opportunity for them to shake things up totally with a fresh 2017 sim. As you say also, it is a limited market - I imagine their main target client is not an flight sim home enthusiast so any decision they will make about development will likely be reflective of that. Causing a development headache for a small 2 person team (for example) add on developer may not be a priority if NASA (or similar) are demanding certain changes/implementations.

If they decide to induce enough changes, this would initially put Prepar3D on the same level as AeroflyFS2 or even FlightSchool.

On top of that, LM is not marketing Prepar3D as a flightsim at all. The "training" that they have in mind is not necessarily pilot training, but

Quote

Users can train anywhere in the virtual world, from underwater to sub orbital space.

The new features revolving around weapons and avatars could be a hint too. Their target market seem to be military organisations (surprise), emergency response outfits and 3rd party system integrators like Redbird.

I suspect that they don't simply sell P3D to NASA. Instead the sell them a custom simulator based on P3D - and collect the money for the systems integration and the development of the custom solution. That could go like this: $2500 for the base license, plus integration effort of 2000 hours at $150 per hour, plus custom hardware for $20K... In that case the end customer (NASA) would not care one bit about what features the base platform has - their only interest is that the solution that they bought is doing what was specified. If they want something more/else, they would have to order this in another individual contract with LM, again based on effort/hours. 

 

[flying_w 58]

1 hour ago, Lorby_SI said:

About the programmatic addons:

This is actually not really a question of 32 vs. 64 bit. The important part is, if the API is kept the same or if it changes. If SimConnect is changed, replaced or altered significantly, every addon using it will simply cease to function. Then the addon has to be reevaluated in all details, as there is no way of knowing if that changed API will behave like the old one did. And if there are enough changes or some crucial part is behaving differently, you can go right back to implement your addon a second time from the start - and there is no guarantee that it is even possible to do what you did the first time.

Depending on what developers are prepared to invest into this very limited market, addons may be adapted - or not. If the developer is still around, that is (see AES and FSX:SE...).

An example: DTG ported FSX to 64bit and named it FlightSchool. But for whatever reason they left out SimConnect - it is not available at all, in fact there is no API whatsoever! So there is no "porting over" of programmatic addons, aircraft systems or gauges - ever.

To get a feeling about what happens if significant items are changed in a simulator platform, take a good look at the XP11 public beta. In one release LR changed some basic parameter about the engine simulation - in the process rendering every single addon airplane useless that before this was deemed compatible.

Best regards

 

 

It's not just the official APIs like SimConnect, but the "unofficial" ones also.  For example a number of us add-on developers interpret the contents of BGLs to get airport information, traffic schedules, etc. simply because that sort of information isn't provided through a regular API.  I would love to see one, but I suspect we'll be carrying on as before.  The question then is will the BGL format change to use 64bit based pointers rather than 32bit?

Simon

[shivers9 1,174]

The answer to many of these questions seem impossibe to know because we do not know to what extent LM has modified the 64 bit version in prep for this big change over. It seem reasonable to asume that from the beginning of their Developement that where possible, they have taken in account that the end game was to move to 64 bits. I expect that we will see alot of conversion type tools to aid and speed up the process. 

[honanhal 1,420]

How about AI traffic? Is that likely to work in a 64-bit sim without changes, or would it need to be updated to work?

Thinking especially about rumors of a new lighting engine and how that would affect it...

James

[WarpD 824]

8 hours ago, Anders Gron said:

I assume you mean... "With each release Prepar3D has moved further and further away from FSX"?

Prepar3D is still using ESP as engine. But Lockheed-Martin has evolved and re-developed ESP into their own version, which makes Prepar3D (again with each new major release) differ more and more from the original ESP code, which FSX is based on. Or have I missed something?

Hope that makes sense, btw... 

ESP is based on FSX... not the other way around.  I dunno why people always say that.  FSX came first.  Then ESP.  Then Prepar3D.  ESP is based on FSX.  Prepar3D is based on ESP.

[anden145 2,285]

28 minutes ago, WarpD said:

ESP is based on FSX... not the other way around.  I dunno why people always say that.  FSX came first.  Then ESP.  Then Prepar3D.  ESP is based on FSX.  Prepar3D is based on ESP.

O.......K..... Now I'm even more confused... 
Anyway - thanks for answering... 

[G-RFRY 1,712]

Over the coming months 64bit will be a big talking point as DTG have now stated they are working on the next flight sim 64bit, one of the reasons why I am holding off some payware products like the 747 will it be a new product or a free upgrade, DTG partnership with ORBX should mean better scenery .

ray fry 

[mtrainer 136]

Someone indicated that the code size will double - not exactly true.  The real change to 64bit is the change to the address pointers, and sure there are lots of these in the ecode as every branch will now be a 64 bit value.  But, that doesn't mean the integers in the current code base that work just fine at 32 bits will need to be upgraded as well.  Although by default the compiler may choose to take all unsigned integers to 64 bit, inside the code that is easily overwritten with a type declaration.  Code size will grow but will not double.  A small performance hit will be there, but will likely be pretty small as processors are fetching well over 64 bits at a time from main system of memory due to a computer science property called "locality of reference".

Mark Trainer