JamesIceland

The Change to 64 Bit - What Exactly Happens?

Recommended Posts

Hi everyone,

I know there is a lot that hints that the next version of P3D (v4) may be 64 bit and may be imminent (imminent being sometime this year...perhaps). Rather than add to the many threads that discuss when/what we will see, I wondered if people could perhaps outline what would actually be required to get things working in a 64bit version of P3D? I'm curious to know in particular how different types of add on may need to be changed/updated or plain totally redone. I've put down a couple of points on my current limited understanding of things but would be great to hear from others about what may need doing.

1) Scenery - As an example Orbx have said that there will be no upgrade fee for the next versions of P3D and that it's already in FTX Central - am I wrong to assume therefore that porting scenery over to a 64 bit sim is going to prove potentially less troublesome? I know they'll need to update their DLL's for ObjectFlow but outside of that. Will this be similar for all scenery developers?

2) Aircraft - I have read that this is where it'll be much harder for developers to transition. Some reports have varied from saying that things would need to be done from scratch, others that code will simply have to be recompiled to 64 bit. What about aircraft like the Majestic Dash 8 which I believe does a lot outside of the sim - would that conceivably be better or in fact worse?

3) Utilities / add ons - I haven't seen anything relating to things like AS2016, AivlaSoft EFB or any of the other add ons that people use outside of scenery and aircraft - would these be affected by the sim being 64 bit or not? I know some run relatively separately and inject via SimConnect. Other examples I guess would be GSX, FSFX or REX products. Some I guess just replace texture/effect files but others maybe don't?

These were just my initial thoughts. If the switch does happen then there is sure to be some time before developers catch up - I'd just be curious to find out what sort of workload there may be and whether the shift to 64 bit could be a relatively smooth one or a lengthy process of updating. I do remember when X Plane became 64 bit but I do not remember whether this caused headaches - albeit it's a totally different platform. I seem to remember the transition being pretty quick though.

Would be great to hear from people who know what it may take to get things working in a 64 bit P3D.

James

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

Hi James

Scenery: Yes Orbx will give free upgrades, but this could send other small financially marginalized competitors broke if they tried to do the same. Scenery is probably the easiest thing for companies to port over if they have the resources like Orbx. 

Aircraft: Will be more complex considering that there will be a need to recompile in some cases but also probably do updates to the models themselves if the new sim has a more complex improved flight model. But the big companies would be able to make the transition pretty easily I'll guess especially if they get early access. The problem will be all the small companies that fresh sales to survive and who won't get early access to beta builds. My guess is no company will offer free upgrades to aircraft you will have to pay again and there will be a long wait in some cases for aircraft especially all of the small aircraft developers in the freeware world.

Utilities: It will be a patch work of some utilities being updated, others not taking a lot of time in some cases. The already entrenched companies like HiFi will probably manage the rewrite of their software without dramas but the small players will need a lot of time to recompile and rewrite a lot of their software and will need you to buy their products again for them to survive. The addons are going to be the biggest problem if you need them.

Basically it is only scenery that has a chance of not needing to be re-coded to work in 64 bit. All the rest probably will because of changes to simconnect and new flight models etc as well as needing to recode 32 bit software.

Share this post


Link to post

Probably separating the scenery / weather and core FDM simulation components of the sim and making their processes run in parallel, like when we use P3D for the visuals of another simulator ( ELITE IFR, Aerowinx PSX... ) could be a nice first move.

Only the scenery / weather rendering side of P3D would go 64 bit on a first update, giving time for developers, and the updated SDK for them to start working on their aircraft updates.

Share this post


Link to post
16 minutes ago, glider1 said:

All the rest probably will because of changes to simconnect and new flight models etc as well as needing to recode 32 bit software.

Thanks Glider - assuming that the only changes is the move to 64 bit then will that make a difference? I'm making an assumption (for simplification purposes regarding my question) that the only major change will be from 32-64 bit - there could of course be all sorts of rendering and code changes in addition which means that it's incredibly hard for developers to switch. But if the change is literally "now it's 64 bit" then what?

15 minutes ago, jcomm said:

Probably separating the scenery / weather and core FDM simulation components of the sim and making their processes run in parallel, like when we use P3D for the visuals of another simulator ( ELITE IFR, Aerowinx PSX... ) could be a nice first move.

Only the scenery / weather rendering side of P3D would go 64 bit on a first update, giving time for developers, and the updated SDK for them to start working on their aircraft updates.

That's interesting, I haven't heard that before - would make sense for LM to make the transition as smooth as possible and if what you describe is something that can be done when moving from 32-64 bit it would seem sensible.

Share this post


Link to post

I will be really disapointed if the old data continues to be used for airports etc.With changes in the magnetic field these are now often very inacurate and no longer reflect the real world.  The problem though is that this means much more of the bse P3D program will need to be changed and it will not be just a recompile which is what Dovetail appears to have done when they recompilled FSX for their Flight School product (64 bit).

Share this post


Link to post
16 minutes ago, harrry said:

I will be really disapointed if the old data continues to be used for airports etc.With changes in the magnetic field these are now often very inacurate and no longer reflect the real world.  

Updating the Magdec file is trivial. it's only one file

here you go : https://www.aero.sors.fr/navaids.html

  • Upvote 1

Share this post


Link to post

Updating the magdec is more complex than that... the magdec used in the real world doesn't update universally.  In fact it gets rather complex where they won't update the magdec used for a given navaid (in other words the magdec used to determine course/radial for that navaid is different than the actual magdec of the region).  It can really mess with approach courses and plates and such.

As for what will 64bit mean.. the code size will double.  The code performance will go down (it has no choice it's literally moving twice the size of data).  The addressable memory will go up, dramatically.  People will complain about the performance issues and lack of addons... then at some point someone will experience an OOM on their system and all *bleep* will break loos.

  • Upvote 2

Share this post


Link to post

None of that happened  when XP went from from 32 to 64 bit. 

  • Upvote 3

Share this post


Link to post

Changing the code to 64 bit will not affect any scenery or aircraft if LM keeps all the current formats. Even SimConnect will continue to work with 32 programs if the old libraries remain. It all depends on LM if they keep the old file formats and interfaces. Most likely they will.

Only stuff that is registered in dll.xml (i.e. running in the same process as P3D) like FSUIPC and others have to be recompiled to 64 bit. 

So, yeah. I'd more expect what Jay said about X-Plane. :smile:

Recompiling such an old rusty hack as FSX to 64 bit is ... well I don't envy the P3D developers.

Alex

Share this post


Link to post

One of the biggest changes will be that everyone on Avsim will have to find something else to moan about instead of OOM issues lol

  • Upvote 3

Share this post


Link to post
39 minutes ago, Chock said:

One of the biggest changes will be that everyone on Avsim will have to find something else to moan about instead of OOM issues lol

.....that wooshing sound you will hear is 100,000 people simultaneously moving all sliders to the right.  This will be followed by 2 years of moaning and groaning about low frame rates.

  • Upvote 9

Share this post


Link to post
2 hours ago, Chock said:

One of the biggest changes will be that everyone on Avsim will have to find something else to moan about instead of OOM issues lol

As you've been here quite a while, you know that won't be an issue... ;) 

Share this post


Link to post

It's like everything  on the Internet. The 90% of the people who are neither techevangelists nor someone with a problem don't feel obligated to start a conversation.

Share this post


Link to post
4 hours ago, albar965 said:

Changing the code to 64 bit will not affect any scenery or aircraft if LM keeps all the current formats

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

 

  • Upvote 3

Share this post


Link to post

If LC could just create an interim 64-bit version compatible (as much as possible) with everything there is today, with the clear benefit of the plenty of memory to spare, and then rewrite everything from scratch so that better stuff could be added later on (years and years to come, decades maybe), IMHO that would be the perfect approach. :-)

Share this post


Link to post

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

Share this post


Link to post
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.

  • Upvote 2

Share this post


Link to post
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... :smile:

Share this post


Link to post
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.

Share this post


Link to post

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

 

 

  • Upvote 2

Share this post


Link to post
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. :smile:

Alex

Share this post


Link to post
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.

Share this post


Link to post
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. 

 

  • Upvote 1

Share this post


Link to post
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

  • Upvote 1

Share this post


Link to post

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. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now