If there was not a USA EAST and WEST for SubLogic's Flight Assignment Airline Transport Pilot, I probably would not be into this stuff as much as I am.  So eye candy matters at least to me.

P3D can run on 32 bits just fine.  But our imaginations need 64.

If there was not a USA EAST and WEST for SubLogic's Flight Assignment Airline Transport Pilot, I probably would not be into this stuff as much as I am.  So eye candy matters at least to me.

 

I was into that USA East & West too.  I remember a winding blue line, with some addon, that I imagined as the real Colorado river. 

 

Back in 94', when I was working on an instrument rating, I had a serious talk, with another pilot, about IFR .  My interest was mainly in mountain flight, because of the sheer beauty of it all.  To be instrument rated, meant more instrument flights to keep current and proficient. Instrument flight plans, just didn't usually go, where I wanted to. So, I dropped the idea for the rating.  I owned an airplane, and for me, real flight was mostly an eye candy thing.  The Grand Canyon, Yellowstone, etc, were only a few hours way. Just a joyride could end up at Yellowstone, which took nearly a day by car.   For simulation, I rate flight dynamics and eye candy quite evenly. For me, one without the other, makes little sense. 

So much conflicting information, older posts saying they are going 64bit, JV saying they're not at the moment. The only people who know the answer to this is LM, and they're not saying anything at the moment. I sure hope it isn't true.

 

I don't think the transition (if it happens) will be as bad as people are making out. When X-Plane went 64-bit, it was a pretty straight-forward, most scenery still worked, and over the course of a few months various planes were updated. In the event that a certain plugin/plane didn't work, it was and still is possible to run the 32-bit version. The transition was pretty painless for most users, and since most developers used third-party libraries for the planes and addons, once the plugin/library had been updated, their planes again started working. Of course, there are many more addons for FSX/P3D and X-Plane was multiplatform and more portable to start with, but if LM also provide 2 executables, the transition will be much easier, and eventually, just like X-Plane, the 32-bit version will become a thing of the past.

I'm hard pressed to understand just why the platform changing to 64bits would affect scenery anyway? BGL files simply aren't affected by address space to begin with...

 

Executable files and dynamic link libraries would be affected, but nothing else that's purely data.

This just needs to be looked at like this, IMHO.  John V has a company that has been making great stuff.  But his statement is precipitous to say the least.  I think of this like I think of PMDG; we'll know from the developer when they decide to tell us.  And since LM hasn't told us anything to the contrary, I'll continue to believe that 64-bit P3D is still in the cards until told otherwise by P3D.

 

We all have read that some out there think Captain Sim products are not very good.  Well, when put up against PMDG, maybe not.  But their L1011 is pretty darn good, and there's a huge welcome banner over at P3D for CS that's just as large as ORBX, so how much weight does JV carry anyway when put into that perspective?

I'm hard pressed to understand just why the platform changing to 64bits would affect scenery anyway? BGL files simply aren't affected by address space to begin with...

 

Executable files and dynamic link libraries would be affected, but nothing else that's purely data.

I've been wondering this myself.  MOST scenery will work just fine.  Those DLLs just can't be that complex.  I see this kinda like Y2K, it's all just hype (hammers table with cane a few times for emphasis).

 

And if LM is doing things right, which in their case (which is an exception) I expect that they really are, all the changes they've been doing, covering most of the code already, are also putting them in line for a quick transition to 64.  I wouldn't be surprised if they cranked it out within the year.   

How long will you fly with just the default?  In fact, if I would stick with all default right now, I would not have any of these non sense OOM problem or stutters etc.  64 bit conversion is not a few months process, it's years.  ASN has not even released an official update yet for 2.5 and it's been two months, just saying.

If the package was 64bit I would fly all day everyday in default, I so not mind it all.

I'm hard pressed to understand just why the platform changing to 64bits would affect scenery anyway? BGL files simply aren't affected by address space to begin with...

 

Executable files and dynamic link libraries would be affected, but nothing else that's purely data.

 

Actually it is mostly the other way around.

 

A lot of the data structures contain pointers or offsets, or simply "int" values which become 64-bit instead of 32-bit unless pre-defined very (VERY) explicitly. Data in file structures may be 16-bit or 32-bit at present, but if they are defined (even indirectly, as many are) as "int", their size will double in a 64-bit compile. 

 

All of the data structures used throughout FSX and any add-ons need to be thoroughly checked for 64-bit compatibility. There are hundreds if not thousands of structure definitions in FS and its interfaces. Each of those may possibly need redefinition -- or may not. it depends how carefully they were defined in the first place.

 

The failure to do so, to double check every data structure and every file structure, will introduce bugs in the end result which might be very difficult to track down. it only needs one little mismatch to really mess things up.

 

I know this from bitter experience, converting a large 16-bit product based around Windows 3.1 and 3.11 WfWG to a 32-bit Windows platform. It is far from trivial, and it is the data that trips you up, much more so than the code itself.

 

Regards

Pete

I'm hard pressed to understand just why the platform changing to 64bits would affect scenery anyway? BGL files simply aren't affected by address space to begin with...

 

 

Even if the format was enhanced by LM (let's call it BGL+, for sake of argument), it wouldn't take much to convert between the new and old versions. The same would be true with other formats like MDL, and GAU. Besides, XML seems to be the common language and the only reason to have some of the so-called proprietary formats is for efficiency. The XML text has already been "compiled" into a format that is more efficient for the sim to read at run time. 

 

 

A lot of the data structures contain pointers or offsets, or simply "int" values which become 64-bit instead of 32-bit unless pre-defined very (VERY) explicitly .  Data in file structures may be 16-bit or 32-bit at present, but if the are defined (even indirectly, as many are) as "int", their size will double in a 64-bit compile. 

 

Unless they didn't directly use ints, floats etc and instead used a more portable solution, such as defining their int types in a header, e.g. dword, dword32, etc.. It's been many years since I programmed for Windows, but I thought this was common practice.

 

One thing that got me in the past wasn't a transition to 64-bit, but a transition from PowerPC to Intel. That took me yonks to go through and sort out, and is not something I want to do ever again

My bet would be LM  would create a 64bit version from the ground up no conversion needed and developers will have a new business niche 

I'm hard pressed to understand just why the platform changing to 64bits would affect scenery anyway? BGL files simply aren't affected by address space to begin with..

 

Some scenery/airport developers are going outside the SDK and attaching hooks to the source to include new features. (That's why, I believe, there are problems wiith different versions of Prepar3D.)

 

An updated version of Prepar3D could include those features in the code. That  could change the  .bgl files - or whatever different were used in future. .gl files have changed over the years and the SDK section on Compiling BGL already warns about backwards compatibitity.

 

I'm simply suggested that if I were to develop for 64-bit I'd take the opportunity to review everything in the model's structure.

The failure to do so, to double check every data structure and every file structure, will introduce bugs in the end result which might be very difficult to track down. it only needs one little mismatch to really mess things up.

 

I know this from bitter experience, converting a large 16-bit product based around Windows 3.1 and 3.11 WfWG to a 32-bit Windows platform. It is far from trivial, and it is the data that trips you up, much more so than the code itself.

Thank you for the explanation. My professional training in CS dates from the heyday of the IBM360, and even then was focused for the most part on what was then known as "Systems Analysis and Design" so I'm most assuredly not au courant on these matters... :Worried:

 

However, although the overhead might be more than could be tolerated, I see no reason at all why "32bit data files" could not be trapped and refactored on the fly to compensate for the issue of data type and size.

 

Alternatively, one could write a conversion utility that would do the necessary refactoring and write out a replacement file... :wink:

Each of those may possibly need redefinition

 I've done this sort of thing before a few times.  Once you get your tools set up, and get into a rhythm it all goes pretty fast.  This is one of those areas of development where you could almost put a timer on it depending on how many lines you need to do, how much it takes to do each line.  There are only so many responses needed to "how do I convert this", and they become a reflex, almost mindless.  If it's more complicated then the code was crap to begin with, not a transformation issue (functioning in 64bit does not mean functioning code). Take one code monkey, train him to do this, feed him well and unleash him, have the owners of each module check his work as he passes through it (thereby they learn the 64bit conversion too), and voila, transformation!

 

The prerequisite of this, the elephant in the room, a single developer needs to be responsible for their own sets of modules.  They are the ones who should understand what the data and interfaces look like, what is expected of them.  They are the ones who go through and say "yes that's right" after the conversion of their hopefully manageable (comprehensible) objects of code.  This is what I believe LM does as a company with software development, and P3D is probably not exempt from that.  

 

Returning to review changes/updates to code I "owned" to a new "owner" is something I've done often.  And I agree, the worst nightmare you can have is working on something that no one claims ownership of.   Software very often fails when management doesn't allow developers to take pride in their work.

My bet would be LM  would create a 64bit version from the ground up no conversion needed and developers will have a new business niche 

 

 

I'll take that bet, cause I''m 100% sure that would never happen.