Then in 2016 or 2017 we will see v4 64 bit...
And we will all start with a clean desk....

 

Bring it on, it's time ;o)

 

 

So Greg i would really appreciate it if you didn't make up things, thank you

 

My comment really had nothing to do with you and was a swipe at JV's comment a while ago that there would be no 64-bit version and whatnot.

JV comments were I believe made to protect Orbx sales,lets face it everybody seems to think a 64bit P3d is going to be better than a 32 bit P3d,therefore a lot of serious simmers will want to switch so why waste money if it is short! purchasing some thing that could be US in mths,I am very choosy what add on,s I now  purchase,due to certain dev,s charging a fortune for the P3d versions of there add ons and the single version liecense,this I think  is short sited on their part and in my opinion will help to kill FSX,maybe some devs think that it is time FSX went away!,Milviz have just announced a P3d only add on so maybe it has started,just imagin these forums when devs say you have got to pay full price for the reworked 64bit version of the add on,

peter

My comment really had nothing to do with you and was a swipe at JV's comment a while ago that there would be no 64-bit version and whatnot.

I was only being silly with you Greg:) I have a dark humor

It seems the thoughts here is that Orbyx is the bee's knee's & woe if we do not have it. (I recall the PMDG discussions).

I think it must be realised that there are upgrades & updates, & we should consider an upgrade as a totally new sim. If some stuff works, then it's a bonus.

Just as FSX was an upgrade of FS9, with a host of compatibility issues, we must consider V3 an upgrade of V2.

Of course the 64bit version must be regarded as a new sim as well, with it's associated DLC's etc.

Even if v3.0 to be released at Fall 2016, it would require a transition period ~6 months for developers to adopt their products. Sceneries without modules, textures' packs, photoscenery should be fine, but 3D planes, internal modules (GSX-like) would require the re-write of a code and this will take time.

 

These look good, where can you get these?

I have not seen these in the states.

 

Ohh, and bring on V3...

FWIW, Beau made another post today in which he referenced v3 AND v4!!!

 

Let the speculation begin........

 

Let's face it, unless LM pulls the plug like MS did a few years ago, they plan to continue development and we are along for the ride.

 

Looks like fun to me.

 

 

Vic

FWIW, Beau made another post today in which he referenced v3 AND v4!!!

 

 

Beau-loody Hell!

Thanks for reporting this. There were a number of difficult edge cases that could not be handled in the same way when porting the extrusion system from v1 to the GPU for v2. We are doing an overhaul to the GPU effects system for v3. The general goal is optimization and performance, but another key focus of this effort has been to improve the rendering of extrusion effects (such as wakes). I will forward this post on to the effects lead to look at. Hopefully it’s already fixed in our internal build.

http://prepar3d.com/forum-5/topic/wakes-with-boats/page/2/

 

 

Beau-low me down!

I did reach out to AMD as well as Nvidia, but last time I checked, AMD did not support CrossFire in windowed applications. We chose to drop exclusive full screen support in favor of a restyling windows to fill the screen in v2. We did this for a number of reasons which I have posted about several times over the last couple years. The long and short of it is that the windows operating system doesn’t really provide a clean way to support multi-monitor full screen experience using exclusive full screen. This unfortunately means that graphics card features that are full-screen-only do no work with Prepar3D. Nvidia has long supported windowed applications in SLI, and recently added GSync support for windowed apps. Windows 10 is re-enphasizing windowed apps by allowing modern apps to run in windows. Given all that, I would be surprised if AMD isn’t working on windowed app support. We are looking into possibly adding limited exclusive full screen support in v3 or v4 in order to support latency sensitive hardware such as VR headsets and 3D projectors, but this would likely be limited to a single monitor or a single view per monitor. Note that our Oculus plugin actually creates it’s own window that does support going to exclusive full screen, so there are potentially ways to work around the limitations of v2.

http://prepar3d.com/forum-5/topic/prepar3d-2-5-crossfire-support/

Beau's second quote made me laugh. We might be doing that for version3, but oh maybe not, it might be version 4. I don't think that his quote is equivalent to anything except some conversational obscurity. "version 4" seems to be in the realm of "we're thinking about it."

 

Let's see what's in version 3 first, before getting too carried away. Oh and not to be too redundant with the excellent posts made by Rob A. a few months ago, but... People are reading too much into what it takes to convert to 64 bit. Most of the FSX/P3D file formats can probably remain intact. Conversion to 64 bit code not the giant hurdle that some here make it out to be.

 

 

I personally feel that if P3D goes to 64 bit, and all the content that users have today will not work with the newer version, many people will just keep flying the current version. 

 

If it were only conversion to 64-bit then I would agree.   But to get something more than just more VAS to play in we really need to access some of the features in DX12 implementation.   IOW, if there were real performance enhancements and new features coming out of DX12 this could sway folks to jump on board with the new P3D:

 

'Now it is time to bring it all together and show how all of D3D 12’s exciting new features can create a truly multi-threaded game on PC, for that all important “Console API efficiency and performance”.  D3D 12 allows for several parallel tasks. Command Lists and Bundles allow for parallel command generation and execution. Bundles allow for oft repeated commands to be recorded and run in multiple command lists several times in a frame or across multiple frames. Command Lists can be generated across multiple threads then fed to the Command Queue for GPU execution. Finally using persistently mapped buffers you can generate dynamic data in parallel. So both D3D 12 and WDDM 2.0 are designed for parallelism, and it is up to the developer what to make parallel. D3D 12 removes the constraints of past D3D versions, allowing the developer to parallelize their game or engine in whatever way makes sense for them.'

I'd be very surprised if they didn't already have a 64 Bit version that they're interally testing.

 

I can just imagine the Lockheed Martin P3D Office...

------------------------

Beau: Well, we can't be far from release now. You do realise that the flight sim geeks over at AVSIM are well aware we're already working on this right?

Saul: Well, we have been dropping hints for ages now.

Wes: Yeah, and I've been quoted numerous times that it's on the roadmap...

Beau: Wes, didn't you leave months ago?

Wes: Oops! sorry. Taxi!

 

*knock on the door*

 

australian voice: Let me in guys, let me in! Are you working on a 64 Bit version in there???

Beau: Of course not Jon, go away! We're a multi-billion dollar defense contractor that's always at the cutting edge of technology, why on earth would we be working on a 64 Bit version? Besides, it'll break ORBX PeopleFlow™, ObjectFlow™, CreatureFlow™ and...

australian voice: ...and don't forget our upcoming 32Bit FlowFlow™ !!

Beau: That's right! we wouldn't do that to you Jon... 32Bit forever!?

australian voice: 32Bit forever!

 

Beau:...has he gone? OK, bring in Rob Ainscough and show him what we've been working on...

Sorry Neil I just couldn't resist:

 

a classic ... I love mushy peas

 

 

 

but... People are reading too much into what it takes to convert to 64 bit. Most of the FSX/P3D file formats can probably remain intact. Conversion to 64 bit code not the giant hurdle that some here make it out to be.

 

I believe LM's approach is to fix what they know is currently wrong and/or source of performance/memory issues in P3D/ESP ... it would NOT make sense to duplicate/migrate to 64bit what is known to be not working as well as it could.  I believe LM want to get to a position where they can feel comfortable with the code base and then move to a 64bit ... I guess V4.0 is out of the bag.

 

Cheers, Rob.

 Neil 

 

 

 

a classic ... I love mushy peas

Mushy peas are the stuff of nightmares.

 

Is that Hale and Pace? from the 90's

 

I believe LM's approach is to fix what they know is currently wrong and/or source of performance/memory issues in P3D/ESP ... it would NOT make sense to duplicate/migrate to 64bit what is known to be not working as well as it could.  I believe LM want to get to a position where they can feel comfortable with the code base and then move to a 64bit.

 

Makes sense to me. While 32-bit has memory limitations, proper resource management is more important that carrying the same inefficiencies to a new architecture. If they continue making fixes to the resource management, then P3D v3 or v4 will be a sale for me.