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

As a coder to a coder: you are right of course. I still think "voting with your purse" works the other way round though. I would really like some of those flaws ironed out, instead of a completely new product where all the misery starts afresh...

 

I'm sorry, I just get agitated every time people start reciting clever marketing gigs. Like "64 is double 32, so it has to be better. It just has to!!"

 

I hope you will agree, that recompiling to 64 bit will only change the game as far as memory / OOM is concerned, right? If nothing else is done, the game will run just the same FPS as before. You will only get your OOM some time later, because the same leak will fill it up eventually. 

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

 

Impossible. All add-ons will have to be recompiled to be compliant with 64-bit.

Share this post


Link to post

 

 


I don't fancy the thought of having to start from scratch all over again

 

Not many people do ... but if the 64bit pay-off is worth it, they will.  FSX and P3D were already into OOMs the day of release.  Without 64bit what are 3rd party devs going to do?  The more realistic their products the more VAS they use ... they were long ago fighting for end user VAS  ... I guess they can just keep asking end user to "dial it back" but that's getting old in this day and age of 64bit.  Just as the end user (most of whom don't code) can't keep saying "the code isn't optimized" ... that's get old after a while too - especially from people that have never seen the code.

 

People will complain, moan, groan, and do the things they usually do when it comes to spending more money (the real issue) and change (the other real issue).  Some will forever stay with 32bit, but I'm pretty sure the majority will embrace change so long as they no longer OOM and they see the benefits of the change.

 

But ultimately 64bit keeps 3rd party development alive and opens many more doors for them to improve reality (beyond just visuals) ... such as much more intelligent AI both on ground, in the air, etc. ... intelligent AI means more VAS as more code is required to implement the intelligence ... just one small example out of a world of possibilities.

 

There are MANY ways to implement 64bit ...  I would guess the BGL will most likely change, DLL for sure (no way around that), etc. etc.  ... but as those changes happen so will the tools eventually.  But some things to think about on the code side:

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384198(v=vs.85).aspx

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384264(v=vs.85).aspx

 

Point being everything doesn't need to change when moving to 64bit ... only some things need to change.  IMHO, I'd guess P3D v2.x has many of these "preparation for 64bit" issues already implemented.  Still by NO means a trivial task ... just perhaps not as daunting ... but all too often one has to get down and dirty with the code to see what issues may surface.

 

The migration to 64bit will probably be slow, but that's ok ... we'll still have a 32bit P3D that we can run while we wait for 3rd party to catch up to 64bit.  But not doubt that 64bit will be a solid foundation for growth in the Flight Simulator market (LR/Austin was aware of this and successfully made that transition, I see no reason why LM can't do the same).

 

Cheers, Rob.


 


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. 

 

So please explain what is the "base code"?  Details please.  Sorry but I don't know any software engineer that has ever claimed their code is flawless -- this is something software engineers just don't do period -- me included.

 

 

 


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

 

Show me LM's or ACE's lazy coding?  As in a real code sample from P3D.

 

Sorry folks, but if you are going to continue to attack LM/ACEs as lazy coders then you better be prepared to back that up with some real code samples from P3D v2.x.  Otherwise this is just unsubstantiated jibber jabber.

 

Cheers, Rob.


 

 


I'm sorry, I just get agitated every time people start reciting clever marketing gigs. Like "64 is double 32, so it has to be better. It just has to!!"

 

Not as agitated as I get when people talk about code they've never seen.

Share this post


Link to post

Well, I'm not convinced. Not all changes are necessarily beneficial, especially when followed blindly.

 

The only glimmer of hope that I have is that LM has practically no business interest in mass selling this product. So they will hopefully only then present a 64 bit version, when they feel it is ready (as opposed to just boosting sales). Hopefully they are not bound to much by agreements with MS about the ESP code base. They will have to massively cannibalize this if they want a remote chance of staying compatible. If they go their separate way, it will certainly be a long one - it will take the 3PD years to catch up to the same standard as they already have.

 

I'm not really sure, but isn't X-Plane actually Java - based? If true, then moving to 64 bit was no great feat after all. But I'm probably wrong about this, I can't imagine getting that kind of performance out of a JRE.

 

But I digress again from the topic. My wish for P3D V3.0: fewer bugs, no new ones. I'm getting too old for that kind of excitement.


Damn, my editor is giving me a hard time.

 

Rob, please calm down.

 

Nobody said or inplied that LM or LR are lazy or dumb coders.

 

The topic at hand was, that seemingly unlimited hardware resources may well lead to these things though (generally speaking). On the other hand, limited resources force you to be  efficient) (generally speaking).

 

Bottom line of all the jabber: there is no magic bullet signed "64 bit".

Share this post


Link to post

I totally agree with Nuitkati. Going to 64 bit will set us back for years. Most people don't have OOMs I think. We just don't shout about it.

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

 

 

No offense my friend, but I think you need to study up a bit more.  Are you running a 32 bit OS?  Do you only have 3GB of RAM installed?  If that is the case, it's that time..... 

 

RAM disk, not needed. If you're running that low on HD space, it's time for a bigger drive.  Or if you have enough RAM where you can afford to take some of for RAM disk usage you should have no issues whatsoever. 

 

You do realize XP10 is 64-bit. It has yet to use more than 4-5 gigs of memory on my machine. Nowadays VRAM is becoming the limiting factor as resolutions increase.

 

 

Again, 64-bit allows the possibility of using more than 3GB of memory.  It's not going to run wild like a lion with it's first gazelle in 10 years and consume every facade your machine. 

Share this post


Link to post

 

 


So please explain what is the "base code"?  Details please.  Sorry but I don't know any software engineer that has ever claimed their code is flawless -- this is something software engineers just don't do period -- me included.

I was replying to Nuitkati. That conversation contains the context as to why I wrote what I did. Not sure what you're trying to get at.

Share this post


Link to post

For me, the graphics are already good enough. We all want infinite frame rates, but I can live with what I have now.

 

How about realistic ATC right out of the box? Nothing would add more to the program as a simulation than that. Then a better standard of flight modelling in the stock planes would be great. 

Share this post


Link to post

Hmmm ... this is starting sound like trolling ... 

 

 


My wish for P3D V3.0: fewer bugs, no new ones. I'm getting too old for that kind of excitement

 

What does that have to do with 64bit ... or 32bit?  Bugs will exist in both regardless ... if you are having a hard time accepting bugs then any software development will be a problem for you, including the very OS/platform these simulators run on.

 

The existence of "resources" (memory) does NOT change how efficiently one codes.  However, the lack of resources can force one into bad design decisions and produce extremely difficult to maintain code with very limited flexibility and a lot of hard dependencies in order to squeeze out that last ounce of performance.  For example, rather than load this data from a file (flexibility), I'll just hard code values ... no flexibility but faster.  

 

In fact, FSX has this, it's that chunk of assembler code -- this was convert in P3D to more traditional VC++ code.  Is assembler code faster, in most cases yes, and it's usually sprinkled in with higher level language code specifically for performance reasons.  It's also VERY hard to maintain and is often NOT thread safe and can trigger a lot of other issues. You want a faster P3D, toss out all that compatibility code and remove the SDK.

 

LM could spend 2 years optimizing P3D 32bit and maybe squeeze 10% performance gain and maybe 5% less VAS usage, with a less flexible product ... OR one can spend a year making P3D 64bit, open the door for 3rd party, then spend another year going to DX12 and have a product that is both incredibly flexible, OOM free, and gains 33% performance in 2 years.

 

 

 


Going to 64 bit will set us back for years. Most people don't have OOMs I think.

 

Many people know how to avoid OOMs ... however, anyone can generate an OOM (even with just a base P3D v2.x install).  Living in the past WILL set Flight Simulation back years ... it already has.

 

If these comments are really just about performance and the lack of desire to buy hardware to meet the demands ... fair enough  ... I can understand your financial concerns over the continued hardware requirements.  But there is no need to make all this other unsubstantiated stuff up -- lazy coders, LM's business plan, etc. etc..  Wait for the hardware to get cheap and come enjoy the show when you're ready.

 

I am calm, but when someone makes sweeping generalization about "lazy coders", "inefficient code", "LM's business plan" ... you triggered a response ... did you expect otherwise from a developer?

 

Cheers, Rob.

Share this post


Link to post

 

 


I'm not really sure, but isn't X-Plane actually Java - based? But I'm probably wrong about this...

 

You're not wrong at all, Laminar get their coffee beans from Blue Mountain in Jamaica. They drink tons of it!

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