I have been in this business for more than 30 years now.

 

Hey nuitkati!  Good to see another high-time coder.  I started in January 1976.  In the Army.  In the Pentagon.  It's nice to get the views of another coder rather than a management type. 

 

I agree with you 100%, except that I suspect that a change to 64 bit will kill EVERY existing addon.  That means starting totally from scratch.  This isn't about cost, it's about the fact that a lot of my favorite aircraft are no longer maintained.

 

I laughed and laughed the first time I read about someone getting an OOM in XPlane 64 bit.  It can happen there, and it will definitely happen in P3D if it goes 64 bit, and it won't take any 144 hours either.  But you're right that it will take a long time, probably years, before there's enough stuff available for P3D-64 to produce an OOM. 

 

Whatever you do, don't suggest to Rob that LM can possibly produce anything resembling sloppy code.  While you and I know better, Rob puts forth the viewpoint that LM does not write the same kind of code written by 99% of the programming community.  I'm going to pretend that this is a semantic issue, that "sloppy code" doesn't mean the same to us as it does to Rob.  Writing perfect code is just too expensive for any application other than medical and a few others.

 

For what it's worth, I've never gotten an OOM in FSX.  I've gotten all sorts of other errors, but never an OOM.  Part of it is because I'm careful what I load up at one time.  If we get a P3D-64, we'll still have to be careful and it'll be rather comical watching people's reactions when they see what happens.

 

Way back in the beginning I was saying they should fix the problems in 32 bit before they try to migrate to 64.  Otherwise, the problems probably won't ever be fixed;  the sloppy code will persist forever, and will bite us eventually.  This is sloppy code left over from ACES, Rob. 

 

Anyway, welcome, and good to see someone else not on the 64 bit bandwagon.

 

Hook

Hi Larry,

 

OOM's in XP10 were a result of end user error ... they either didn't have the physical RAM, or set a very small paging file, or were trying to run 32bit add-on, not a 64bit one.

 

I don't understand how you can comment about sloppy code without actually seeing the sloppy code?  Saying 99% of the programmers are sloppy seems like a rather sweeping generalization.

 

What I do know from LM is that there is considerable "compatibility" code that is NOT efficient ... this compatibility code is there to support those older products you want to keep.  LM have removed some of the code dealing ASM because it was causing performance problems ... and many 3rd party devs don't like that they did.

 

So in other words, yes there is plenty of compatibility code LM can remove to improve VAS usage and performance ... but then they're back at square one and you have a 32bit product that's not compatible with add-ons.  So the path to improve VAS usage and efficiency will provide the same "breaking" end results as the path to do a 64bit product.  Either way, those cherished add-ons will not work.  So ... do you really want LM to remove that "sloppy" code?

 

I'd rather see LM focus on the long game, not the short game.

 

Cheers, Rob.

 

 

It's my opinion. You're reading an internet forum, you know that don't you?

 

As Mark Twain said "Believe none of what you hear and half of what you see" is even more important on the internet.

Hi Hook,

 

many thanks for your kind words! I will have to admit though, that I have converted to the dark side. For the last decade I have been working as project manager /PMP in enterprise application development. After humble beginnings in 82 and some diversions I've been more than 20 years in total now in the same IT subsidary of a rather large company. Large meaning the 60-billion-$-annually kind. I probably have some ideas about what the P3D team are facing and they have my utmost respect for pulling it off. But my views on software development and the 'can and can't or even should do' in that kind of environment would, if uttered in this forum, lead to my being drawn, quatered, burned at the stake and then beaten up. So I just try to get people to think of the possible consequences if their wishes come true, and maybe get a measure of reality squeezed in the middle. Not that anyone needs to care, it is just my opinions, nothig more.

 

Best regards - and let us all have that beer sometime

I'd rather see LM focus on the long game, not the short game.

 

Cheers, Rob.

 

This is why I'd expect Lockheed Martin to introduce 64-bit with the next major version of Prepar3D; they can add 64-bit and remove the compatibility code at the same time, because both will break add-on compatibility anyway.

Compatibliity code isn't necessarly a problem - many established applications have it.

Sorry, please allow me just one more.

 

I really like the idea of coding to the business requirements, and I envy you, Rob. I really do.

 

I always seem to get all those requirements at once and then some. In my experience everyone just tries to keep up to the best of his/her abilities, no room for anything else. And every day you get asked by management if you have even earned your air today and why are you still here, if there are so many fine opportunities out there with the other companies. 

 

I formally apologize for digressing from the topic.

Yes - this topic is getting close to Jumping the Shark...

OOM's are a result of memory not managed correctly.  Period.   It's a message from the operating system that you haven't capped off your memory usage and you're bumping up on the memory space allocated to your application.  You can handle this message programatically, but not easily within the application, and you can manage to put limits on memory according to what is available according to the operating system, but not easily.  If I were to chose what to do, I'd do option number three, handle them the best one can with the time allotted by economists and your company's CFO, don't do anything you wouldn't have to do for a 64bit port, and begin to think in 64bit while you address your clients immediate concerns about the software and how they feel while using it.  How people feel is often more important, like how McDonald's makes so much money making so many feel like they're getting a great dining experience; just make sure it's good for them too.  Truth of the matter is nothing is ever user error, just misguided users.

 

 

What I do know from LM is that there is considerable "compatibility" code that is NOT efficient

 Also known as feature bloat.  However, if there is time and money, you can make an application compatible with goat utters, or duvet covers, or guitar strings.   

you can make an application that talks in a way that is efficient to the main application, that speaks the language of all of the addons.  A small department could be made just for that purpose, or a small business.   You just need to convince somebody that somebody is going to pay for it, be it a beer, or a happy meal, or a mortgage payment, whatever one can be talked into it for.

To me, Prepar3D is like the moon shot, or the space shuttle.  The dividends reaped aren't always direct in a revenue stream, but it pays multiples in the seeds it plants in the minds of the people that once saw such wonders.  That's the kind of growth McDondald's gets from a happy meal.

Compatibliity code isn't necessarly a problem - many established applications have it.

 

LM have indicated to me it IS a problem ... they have also removed some ASM support because it was too much of a problem. Unless Wes, Beau, Adam, others have told you otherwise, this is the information that LM presented to me.

 

 

I really like the idea of coding to the business requirements, and I envy you, Rob. I really do.

 

Don't envy, I have to write the requirements also - I'm the PM, the IT person, lead programmer, web developer, and security officer (PCI/PADS compliant) all bundled up into a single resource ... me (fortunately I do have a few other programmers and testers and back IT people working for me so not entire alone).  It has taken me a long time to manage my way into a being able to code for the long game ... I had many years at large corporate institutions coding the short game ... I was finally able to remove myself from that madness and find a sane approach to software development.  Since then the fires are fewer and so much easier to manage ... but it was difficult to get into that position (some good times some bad times).

 

As far as compatibility code and efficiency both in VAS and performance, I have yet to see any such code after 34 years of coding.

 

Basically if the compatibility code exists it's already increased VAS usage and reduced performance.  How could it be any other way?  Example:

 

Select case Alpha

   Case FS8

        BuildGeometryFS8Way

   Case FS9

        BuildGeometryFS9Way

   Case FS10

        BuildGeometryFS10Way

   Case Native

        BuildGeometryNativeWay

End Select

 

Four Methods (chunks of code) that are memory resident ... and a branch tree to call the appropriate method ... that's clearly not efficient, especially if this has to be evaluated on every frame.  The efficient approach would be No branch at all just call BuildGeometryNativeWay ... one method, no branch, but no compatibility ... that's going to us less VAS and execute faster.

 

Topic hasn't diverged too much, people just expression what they want and think they want in an as yet unknown P3D v3.0.

 

Cheers, Rob.

Four Methods (chunks of code) that are memory resident

 

 

So you put this into another application, have the application do the build, translate that build into p3d 64 "meat", and have that application send the meat to a dll that makes the calls to P3D to inject the beef into p3d.  Sorry, I guess I'm hungry.  I want a happy meal for these lines of psuedocode!

 

But you are right, going forward to 64, backwards bloat has to go.  It's probably causing the stutters.

(When I can take off from KHAF, fly over SFO airspace and straffe my liberal comrades at Berkeley at 30+ fps and 5760 I will vanish into Nirvana.  It's soooo close now, and a another 780 and a little SLI I will fade away ....  I've been away from the sim for a while, it's truly beautiful, esp with HDR fixes.)

P3Dv3.0, let me dream about this. I am not a software guy so I do not know technical details.

• Non flat airports
• Better rain and snow  
• Rain on windshield (I know some payware aircrafts have.). 
• Better flight dynamics (l really like flight dynamics in DCS. I like the one of MJQ400, too)
• Better AI and ATC behavior, support for SID and STAR (at least make it easier for 3rd party to develop better ones)
• No sudden change of clouds (I am using Opus, is it solved in ASN?)
• Better AA (can LM do any more about this?)
• Better sound, especially environmental sound (here again, I really like the sound in DCS too)
• Modeling of pilot and copilot (is it possible even now? Only a framerate issue?)

I guess that not many are of LM’s interest. But I am still wishing....

 

+

• 64 bit

• New rendering engine with an innovative, global lighting system

• Detailed terrain for the entire world with very precise elevation data

• Plausible world ' through auto-generated (AutoGen) with almost all roads, waters

My worst nightmare is that all the people claiming that they never experienced OOMs, nor sees the necessity of a 64-bit simulator is going to make LM think twice instead of just GO FOR IT!

 

 

LM have indicated to me it IS a problem ...

 

Did you actually read what I wrote?

Hello Gentlemen,

 

If have been into flightsimulators since FS8 and changed to P3Dv2 from FSX. Although I personally think LM has brought P3D to a new level, and did a good job in cleaning up the code, I do think that there is still room for improvement.

 

That said I think for LM it will be a business decision. If the professional costumers (talking airlines or military's) will need 64bit support - they will provide that. I don't think that the needs of the professional "simmer" (talking majority of us), necessarily correlates with the needs of the airlines and military. Airline training centers hardly ever simulate a complete flight from one Airport to another.... they use the sim more for actual scenarios, landing and emergency procedure training and P3D provides that also in 32bit. One highly detailed airport, one highly detailed Aircraft even with wether etc usually does not cause a problem, the OOM's, according to my experiance, usually occures during long flights - or once the destination Airport loads into the sim.....

 

That said, personally I hope they keep improving on the 32bit code - However, if P3Dv3 is not 64bit, I will definately not shell out another $ 200.- or so dollars for an improved 32bit application - that will still be unable to handle a substaintial amount of addon scenery....

 

As far as I see it - and I'm no software developer - its just impossible to fill 320 000 lbs of fuel (777) into a 46 000 lbs tank of a 737......

 

Of course - if it is 64bit, I'd propably would talk to my bank if necessary to get my hands on it! If it is then even able to keep some of the compatibiliy ((lets call it) pure FSX/P3Dv2 code) with some of the newer scenery addons for P3Dv2 - perfect.

 

regards