Prepar3D v3.0?

[Timberleaf 1]

What would this even look like? Features? Considering the advances that LM has made in the development of v1 and v2, I toy with dreaming of what v3 could bring.

[G-YMML1 582]

64 bits please. That's all.

[TrafficPilot 121]

+1 64bit version.

 

Accurate flight dynamics for default aircraft including more trainers and less P38/Constellation/Carenado.

 

Ability to switch off "rain fx".

 

Adjustment slider for autogen size.

 

Debug window!

[Bakern 31]

64 bit version and i'm happy.

[DylanM 1,069]

If they have to, I'd actually prefer if they threw the baby out with the bathwater this time, and aim for a future-focused core sim platform (DX12+, logic optimization, 64bit, etc.) rather than backward compatibility.

 

The difference this time is that the 3PDs are already enagaged, so having them around early in partnership could mean their products are ready for release in tandem (making the transition much less painful)...

[DocBird 79]

JV from orbx stated that the update of their addons for P3D 3.x would cost a small fee. To me that didnt Sound like they would have to redo everything from the beginning...

64bit would be nice. Better graphic would be a must.
 

[willywonka 36]

 

 

Ability to switch off "rain fx".

Or, just give us new rain shaders already B)

[Lorby_SI 2,036]

Funny how quickly people jumped on the 64 bit wagon. There is nothing to be gained by this, except you get your OOMs a bit later. And don't forget that those 32 Gigabyte of RAM need to be filled from your SSD or harddisk - welcome to the next bottleneck.

 

I would welcome backward compatibility, considering the pile of money I have already spent. So 32 bit it is. But I'm hoping for improved memory management and garbage collection. Maybe a swapfile like in the old days, that one could move to a RamDisk.

 

At least 32bit should force devs to optimize their code. It is not unheared of that seemingly unlimited hardware power leads to sloppy programming.

 

Just my 2 cents...

[dgraham1284 92]

Funny how quickly people jumped on the 64 bit wagon. There is nothing to be gained by this, except you get your OOMs a bit later. And don't forget that those 32 Gigabyte of RAM need to be filled from your SSD or harddisk - welcome to the next bottleneck.

 

I would welcome backward compatibility, considering the pile of money I have already spent. So 32 bit it is. But I'm hoping for improved memory management and garbage collection. Maybe a swapfile like in the old days, that one could move to a RamDisk.

 

At least 32bit should force devs to optimize their code. It is not unheared of that seemingly unlimited hardware power leads to sloppy programming.

 

Just my 2 cents...

 

 

There is a lot to be gained by 64-bit.  The 32GB of RAM are not filled from your hard drive.  It utilized by the RAM.  64-bit has  a limit of 16.8 million terabytes of usable RAM.   32-bit has a 3 GB limit. 

 

The Z77/87/97 chipset, anything that isn't server grade/X79/99 can address a maximum of 32GB of memory. 

[Lorby_SI 2,036]

The 32GB of RAM are not filled from your hard drive.

 

Sorry, but those 32 Gig of data have to come from somewhere, right? They will have to get loaded from your HD or SSD, no matter what they contain (textures, objects, code artifacts like DLLs, whatever). This will have a performance penalty if not done right (=eg not optimized to what is actually needed but instead blindly stuffed in there because "size doesn't matter"). Care to remember the days when we had games stretched over 6+ CD-ROMs? Same thing basically, methinks. Way too much superflous stuff just because it was possible to do.

[Christopher Low 5,332]

64bit version with compatibility for existing addons. It has taken me years to get FSX/P3D updated right across the UK. I don't fancy the thought of having to start from scratch all over again <_<

[dgraham1284 92]

Sorry, but those 32 Gig of data have to come from somewhere, right? They will have to get loaded from your HD or SSD, no matter what they contain (textures, objects, code artifacts like DLLs, whatever). This will have a performance penalty if not done right (=eg not optimized to what is actually needed).

 

You are talking about pagefile. It will not use more than you have.  Nor will it consume that much data.  That would indicate some seriously poor coding skills. Video transcoding is about the only thing, that a consumer, would need that much memory for.  Or virtual machines like myself.  

 

64-bit would only allow you to use beyond the 32bit limit currently imposed. 

[Lorby_SI 2,036]

You are talking about pagefile. It will not use more than you have.  Nor will it consume that much data.  That would indicate some seriously poor coding skills. Video transcoding is about the only thing, that a consumer, would need that much memory for.  Or virtual machines like myself.  

Exactly, That is what I'm wary of, not necessarily poor coding skills but definitely lazy coding.

 

And true enough, it wont consume that much data - so basically 64 bit isn't needed at all, right?

But how much memory is actually needed for a software like P3D that needs to keep an eye on HD/SSD latency too, just because of the size of the data chunks? Hard to tell, right? Maybe this could be done like in the good ol days too, with a swapfile that I can move to a Ramdisk if need be....

[CaptKornDog 281]

64 bits please. That's all.

This.

 

I have FSX (finally, 8 years later) and my system to where I can enjoy (mostly) stable performance and a fair portion of the originally intended eye candy. I'm not really intending on considering as an option until it's 64-bit (which, may or or may not be, a game-changer).

[SKEWR 364]

Exactly, That is what I'm wary of, not necessarily poor coding skills but definitely lazy coding.

 

And true enough, it wont consume that much data - so basically 64 bit isn't needed at all, right?

But how much memory is actually needed for a software like P3D that needs to keep an eye on HD/SSD latency too, just because of the size of the data chunks? Hard to tell, right? Maybe this could be done like in the good ol days too, with a swapfile that I can move to a Ramdisk if need be....

Speaking as a coder,: Yes, elegant solutions are desired. Efficient base code can do wonders. If the code was tight and everything worked well, then I'd think you'd be correct in staying at 32 bits.

 

But...

 

We already know the base code is not 100% flawless. 

 

As an end user if I can fly the 777, at 30+ FPS, with Manhattan X, and addon NYC area airports WITHOUT OOM, then I don't care what's going on under the hood. I don't care if the computer addresses 3 GB or 23GB. Ram is not that expensive so I'll spend to get what is necessary for the best experience. As an end user, I CAN NOT spend more to get better code.