You guys do realize that a hobby is something you're supposed to actually *enjoy*, right?

 

Since when? :Whistle:

I'd rather they fix feature memory bleeds on a 32 bit platform than deal with sloppy programming on a 64 bit platform. Programmers tend to get lazy when resources are plentiful

 

 

 

I've been in software research and development since the mid 80's and a preliminary observation that I can safely make is that the 2.1 patch should have been tested for at least another month. The autogen bleed, whatever its source (XML vs compiled XML) should have been picked up by proper quality assurance efforts.

 

These are two VERY different statements you've made.  But just curious, how would expect a programmer such as myself to respond to a sweeping generalization like this?

 

On your second statement, I agree, more testing should have been done ... in fact, I started a thread on the P3D forum asking LM to open up the Beta program.

 

As far as OOMs and stutters go, we're all in the same boat and can only guess at the cause, to suggest otherwise is purely an assumption.  

 

IMHO, FSX/ESP has exhausted itself, sorta like beating a dead horse and trying to make it come back to life.  But I'll keep supporting 32bit in the hope it eventually brings a 64bit simulator ... but if you think LM is going to solve the OOM problems, I will guarantee you that will ONLY happen if they make serious restrictions the those sliders that make the simulator "more" realistic visually.  

 

But if you or anyone is really interested in pushing flight simulations to the next level (and not only concerned about your past expenditures), then that's going to be a 64bit path (along with all the other "simulations" and games that have long since moved to 64bit path).

 

But with that said, I agree, I do think it's important they get a stable 32bit version going before moving to a 64bit version ... but be aware, stable may mean heavy restrictions on LOD and visual details and hence not a huge benefit over FSX and hence no draw of users from FSX to P3DV2 and hence no 3rd party support.  So it's definitely something to think about, LM banging away trying to squeeze a product even more, or look to the bigger picture, the future.  If they build it, we will come -- especially when the entry fee is only $10 to try it.

 

 

especially when the entry fee is only $10 to try it.

 

I wish I had gone down that road :lol:

Enlighten me, how are they NOT optimizing memory?  Details please ... not assumptions.  And be sure to give those details to LM so they can address them

 

64bit address space provides considerably more than 192GB, FYI.

 

And finally, please tell me exactly how "we programmers" get lazy when not restricted to a 32bit address space?

 

An easy analogy with data types... using 'long' or 'float' all the time instead of 'small int' when small integers is really all you need. Software optimization skills come with experience.

 

4Gb of addressable memory provided ample space for a viable simulation as proven by version 2.0.

If you tinker with Sweetfx, it's as real as its gets with FSX. P3D does not even come close, and HDR is way too dark imo.

 

FSX+Sweetfx is simply incredible when tweaked right. Pictures added cause pics are cool.

 

 

 

 

I'm sure it's a lot better than FSX, but truly I find those screenshots look no better and maybe worse than what I'm seeing w/ V2.0/2.1 in P3D.   But...I haven't seen SweetFX myself personally so really I can't compare from my own experience.    A huge benefit though is the superior smoothness I see w/ P3D V2.0/1.   I had excellent smoothness in FSX, but this is clearly a cut above as in pure floating butter Slick50 PFTE Dry Graphite!!

 

If I tried to go back to FSX I'd have to add SweetFX I'm sure but as I say right now I find the visuals in P3D (w/ FTXG & REX4) to be jaw-droopingly excellent--however w/ water that I could only call fair to good. 

 

 

But just curious, how would expect a programmer such as myself to respond to a sweeping generalization like this?

 

Hopefully the same way I did, by understanding that programmers can't always put max effort into a project.  He used the term lazy, I used the term sloppy, and they basically mean the same thing.  But no one has unlimited time, and sometimes time constraints cause suboptimal procedures.  Rushed might be another synonym for the same thing.

 

He didn't call you lazy, he didn't call me lazy, but I'll admit to being that way a few times.  Read some code you wrote 10 or 20 years ago and marvel at how bad it could be.

 

Hook

As far as OOMs and stutters go, we're all in the same boat and can only guess at the cause, to suggest otherwise is purely an assumption.

 

I never had a single OOM in FSX nor P3D 2.0--VAS would stay around 2.3-2.6 or so most of the time for hours.  Now since installing 2.1, in under 10min it hits the 4Gb wall and that's all she wrote.  I'm not sure if I'm going to uninstall everything and park it for a while, or reinstall 2.0 w/ it's other but certainly less severe issues than this.  This is a show stopper now.

An easy analogy with data types... using 'long' or 'float' all the time instead of 'small int' when small integers is really all you need.

 

This type of statement would be pretty insulting to Beau, LM, Aces, or anyone that has worked at the core aspects of FSX or ESP.   Although I'm sure programmers exists that don't perform best practices, they most likely wouldn't be involved in the development of highly complex flight simulation software.

 

4Gb of addressable memory provided ample space for a viable simulation as proven by version 2.0.

 

The same OOM issues are in P3DV2.0, in P3DV2.1 in FSX, FSX SP1, FSX SP2, and FSX Acceleration ... can you see the pattern?  All 32bit.  To suggest that everyone that worked on these five products is "sloppy" and/or doesn't have the basic fundamentals of best practices (keeping in mind that none of us has ever seen the code) seems to be extremely judgmental.

 

Maybe Phil Taylor can chime in and defend the crew that worked under his management.

 

But 4GB is not ample, it wasn't ample back in 2006, and it's no more ample today ... it's just a huge restriction and ironically it's probably the biggest restriction for 3rd party development (as they are constantly worried about staying within the bounds of 32bit).  But look at the rest of the industry, most "simulations" are now 64bit, many games are even 64bit ... are all developers just lazy and sloppy?

 

But again, how is LM or Aces or anyone for that matter going to be able to manage memory when they have "limited" control over resource release which is governed by the OS?  Tell Microsoft to change their OS?  

 

And again, V2.1 does appear to have issues, I've found a few (as have others) ... and again, resulting in my request to LM to open up beta ... in this thread I started: http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=5603

If you tinker with Sweetfx, it's as real as its gets with FSX. P3D does not even come close, and HDR is way too dark imo.

 

FSX+Sweetfx is simply incredible when tweaked right. Pictures added cause pics are cool.

 

 

 

What is that red plane in the first picture? Amazing how FSX still looks a whole lot better than P3D v2. Sigh. 

A brief summary of my experiences;

 

FSX - Ok performance and pretty stable. I have mid-range hardware at best and however I tweaked, I struggled to get photoscenery fast enough (which I have a lot of) to load in heavy-load situations. DX10 only used as it made a big difference on my machine.

P3D2 - Much much better performance, and smoother but pretty unstable and quite easy to OOM.

P3D2.1 - Even faster loading of photoscenery and smoother with it and a lot more stable. I am rather impressed I have to say. But I can still OOM fairly easily with anything above 1024 textures.

 

However I am very happy - yes there is work to do but, in my experience at least, this is a massive step on from FSX.

 

 

This type of statement would be pretty insulting to Beau, LM, Aces, or anyone that has worked at the core aspects of FSX or ESP. Although I'm sure programmers exists that don't perform best practices, they most likely wouldn't be involved in the development of highly complex flight simulation software.

 

You can find examples of code not using the "best practices" in textbooks.  Some of these have had me scratching my head.  "Why the heck did he do *that*?"  I figure some of this stuff must be simplified for textbooks. 

 

But Rob! It's OK!!  It happens!  Sloppy coding finds its way into production systems.  There are ways to prevent most of it, but they can be time consuming which means expensive.  Think peer code reviews.  Everyone reads everyone else's code... all of it, and it's discussed in meetings.  You can imagine all the advantages and disadvantages.  I've only seen it used twice, once as a tool, and once as a weapon (don't ask).  In both cases it was required by the client, which ultimately was the US Government, which had deep pockets and usually moved at a glacial pace anyway.  None of the stuff I worked on in the Pentagon had peer reviews, it just worked.  My payroll code wasn't reviewed, only the design and then only by my supervisor (and maybe one or two others, I wasn't present at the actual review). 

 

I've written code that my successor called extremely sloppy, but I was writing an assembly language device driver for a Z-80, right down to the bare metal, and expected it to have to be maintained by someone who wasn't an assembly language programmer.  His first change broke the code (it had stringent timing constraints and he ignored that).  He eventually got it fixed... I think.  "You could have saved 128 bytes!!"  One man's sloppy is another man's elegant. 

 

Don't sweat it, Rob.  I only met one programmer in my entire career who could write textbook perfect code as a rough draft.  For the rest of us, getting it to work correctly within the constraints we had was good enough... even on a payroll system where mistakes are not an option.

 

Hook

A few days later, on January 20th, he qualified the previous bare statement by saying "They haven't announced anything yet..." the which is simply nothing other than the bare truth. They haven't "announced" it, yet.

 

I'm not clear about the purpose of  this post.

 

You said "They haven't announced anything yet..." which exactly what I said. If and when Lockheed Martin has something to say  it will then make an announcement.,

When did we start seeing stutters and other data/handling/loading/unloading  problems in simming?

 

 

....   :mad:  Autogen   :mad:  ....

 

  Always been a problem

What is that red plane in the first picture? Amazing how FSX still looks a whole lot better than P3D v2. Sigh. 

 

It's the Lancair Legacy from RealAir.

This type of statement would be pretty insulting to Beau, LM, Aces, or anyone that has worked at the core aspects of FSX or ESP.   Although I'm sure programmers exists that don't perform best practices, they most likely wouldn't be involved in the development of highly complex flight simulation software.

 

A software developer with thin skin doesn't last long in the industry. I'm going to assume that your long experience in IT has more than convinced you of this while spending unpaid overtime laboring on a misquoted project so that your boss can finally get his hands on the money to pay you

 

With very little margin for error and exposure to an aggressive industry and clients, at minimum you need to put in place a basic test plan followed by adequate QA.... Unless you like to listen to this kind of music at every release. Without Q/A, the tremendous improvements and visuals offered by P3D get overshadowed by a simple clogged drain filled with veggies. A 64bit environment would obviously let sloppy developers off the hook as the sim could withstand an addressable space bleed until their next paycheck LOL

 

Side note... If 4Gb VAS is not enough, why do companies like Rex bother with 4096 textures on 32bit sims ?