Sign in to follow this  
Timberleaf

Prepar3D v3.0?

Recommended Posts

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.

Share this post


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

+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!

Share this post


Link to post

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)...

Share this post


Link to post

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.
 

Share this post


Link to post

 

 


Ability to switch off "rain fx".
Or, just give us new rain shaders already B)

Share this post


Link to post

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...

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post

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 <_<

Share this post


Link to post

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. 

Share this post


Link to post

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....

Share this post


Link to post

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).

Share this post


Link to post

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.

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
Sign in to follow this