Not mentioned here is that many fail to understand that more VAS will usually always means worsened performance, a certainty on poor computers. Finding a way to get around an error which actually provides an artificial preventative limit to burning your sim into FPS meltdown seems counter-productive to me.

 

For me it's far better to forget about 64bit and find a way to maximize quality whilst improving performance through more efficient handling of the simulator environment. That has always been a far larger problem than some error we can all very easily avoid through a little careful thought.. This would also benefit every single customer as opposed to the hardcore tweaking simmer who wants 4096x4096 textures across the board.

 

It really would not surprise me if the second we went 64bit, these forums would be awash with people complaining of poor performance as their computers are strained even further beyond what is possible now thanks to the OOM error.

 

 

 

 

It really would not surprise me if the second we went 64bit, these forums would be awash with people complaining of poor performance as their computers are strained even further beyond what is possible now thanks to the OOM error.

 Unless LM did everything they were supposed to do to optimize before the conversion.  In other words, turn on the water after the pipes are clear.

Well, big discussion and especulation here!. Supposedly John Venema is ORBX CEO, right?. Well, is too simple, let's LM representatives make an updated statement about the future of P3D 64-bit and then we'll see.

This is like if LM makes an statement about ORBX next releases, a bit weird, right?.

Edward

 

 

The failure to do so, to double check every data structure and every file structure, will introduce bugs in the end result which might be very difficult to track down. it only needs one little mismatch to really mess things up.

 

My understanding is that only pointer types are affected - but not ints

 

Basic data types remain 32 bits in length, so there is no change in the size of data on the disk, data shared over a network, or data shared through memory-mapped files. This relieves developers of much of the effort involved in porting 32-bit code to 64-bit Windows.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384083%28v=vs.85%29.aspx

Now lets think on this. Most of us already run 64 bit OS. 32 bit programmes run fine just not 16Bit. Our office still only runs 32  bit simply as 64 bit breaks to much stuff we use. P3D is fore most a FLIGHT SIMULATOR. Most of there clients like small training schools simply could not afford to respend huge amounts of dollars just to upgrade software that is working fine for the training schools. As for teh military what do they care they blow up stuff not look at pretty scenery. Now for the small training schools all they want is the most realistic rendition of the area they train in to make it easy on there students as you will find many request by trainy pilots in teh forums ask. JV ceratinly has nothing to loose either way. Me Im haapy FSX does what I ask of it.

I drive by the LM assembly in Marietta, Ga on a regular basis.....................If you all want me to, I can stop by the information window and ask for a clarification on this matter. 

Unless they didn't directly use ints, floats etc and instead used a more portable solution, such as defining their int types in a header, e.g. dword, dword32, etc.. It's been many years since I programmed for Windows, but I thought this was common practice.

 

Yes, you'd think that would be safe wouldn't you?  But look at how these are defined:

typedef unsigned long       DWORD;
typedef int                 BOOL;
typedef unsigned char       BYTE;
typedef unsigned short      WORD;
typedef float               FLOAT;
typedef FLOAT               *PFLOAT;
typedef BOOL near           *PBOOL;
typedef BOOL far            *LPBOOL;
typedef BYTE near           *PBYTE;
typedef BYTE far            *LPBYTE;
typedef int near            *PINT;
typedef int far             *LPINT;
typedef WORD near           *PWORD;
typedef WORD far            *LPWORD;
typedef long far            *LPLONG;
typedef DWORD near          *PDWORD;
typedef DWORD far           *LPDWORD;
typedef void far            *LPVOID;
typedef CONST void far      *LPCVOID;

typedef int                 INT;
typedef unsigned int        UINT;
typedef unsigned int        *PUINT;

The basic types they are derived from, int, short and long, and probably even the qualifiers near and far, are relative to the main size, 32 or 64 bits. 

 

In fact I found an MS reference stating "Win32 does not distinguish between near and far addresses", but I've lost it again.

 

Microsoft did devise new types which are specifically 32 or 64, (see

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384264%28v=vs.85%29.aspx

but I don't see them used in most of the data related to or used in FS -- just take a look at the files, especially the headers, supplied in the FS SDK.

 

I think even the 're-written in C++' FS code precedes this period of 32 plus 64-bit OS availability and consideration.

 

My understanding is that only pointer types are affected - but not ints

 

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384083%28v=vs.85%29.aspx

 

Ah, if that is indeed the case it may be a bit easier to convert than I thought. When I get time I may just experiment converting one of my smaller programs, see what happens to the data.

 

But then, even if it's only pointers which need to be watched, and those don't play a real part in the external data structures (pointers in BGLs and such tend to be relative offsets, not true pointers) they do form an integral and important part of internal data structures being used between the "black boxes" C++ class style programming demands.

 

Regards

Pete

 

 

Ah, if that is indeed the case it may be a bit easier to convert than I thought. When I get time I may just experiment converting one of my smaller programs, see what happens to the data.

 

I found this in the same link that explains Microsoft's thinking;

 

In 64-bitWindows, this assumption of parity in data type sizes is invalid. Making all data types 64 bits in length would waste space, because most applications do not need the increased size. However, applications do need pointers to 64-bit data, and they need the ability to have 64-bit data types in selected cases. These considerations led to the selection of an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.

 

I found this in the same link that explains Microsoft's thinking;

These considerations led to the selection of an abstract data model called LLP64 (or P64)

 

Now if this is not a coincidence I don't know what is....  its too close P64 ,LP64....I like the ring of it 

Prepar3d 64..or Lock Heed Martin P64

 

just a thought.

 

 

Now if this is not a coincidence I don't know what is.... its too close P64 ,LP64....I like the ring of it

Prepar3d 64..or Lock Heed Martin P64

 

Not really, as far as I am aware there are also LLP64/IL32P64, LP64/I32LP64, LP64, ILP64,and SILP64

Quote from an interview with Jarrad Marshall at SF :

 

Talking about the future, P3D continues to impress (with each new release adding additional features), so as a developer, what key features would you like to see implemented in future releases?

 

"This is a question I get asked quite a bit actually. Lockheed Martin have been keenly listening to our feedback and requests for features, something that we have all been very grateful for.

We have a couple of issues and features that LM are working on at the moment, but these are more of a back-end technical nature. In terms of key features, I'm very much looking forward to having 64-bit compatibility, as this will open the door towards implementing more details and features in my products. Aside from this, the ability to have a performance-friendly method to implement conditional models (such as seasonal components) would be brilliant. "

 

mgh, on 28 Mar 2015 - 5:12 PM, said:

My understanding is that only pointer types are affected - but not ints

 

https://msdn.microso...3(v=vs.85).aspx

 

Ah, if that is indeed the case it may be a bit easier to convert than I thought. When I get time I may just experiment converting one of my smaller programs, see what happens to the data.

 

 

Yes.  As I understand it is about the memory, not the data types.  It's really not all that dramatic; much like taking the top off a jar.  Whether you use the space outside of the jar yet is not what you are concerned with yet.  So conversion is easy, not a big event.  Utilization is another story, but can be done just like other incremental builds and feature addons.  

 

Just doing a search "common issues converting to 64 bit code" what you find is most of the issues stem from low quality code to begin with.  Read: inappropriate data types

 

However, In the case of P3D, conversion is a large and dramatic event because it makes third party dll developers cry.  This is really the issue we are talking about here.

 

Could there be a way to address this with a stub for those dlls in 32bit space that will work in with the 64bit space?

I think we have to stand back and see why JV has made this announcement which appears to be the opposite of what he and others 3rd party companies have intimated in the last few months. I believe it is quite clear that orbx/ftx  sales are suffering because they perceive that the general public , quite understandably, is holding back on purchasing their products, because the general public understands, whether correctly or not , that there is a 64 bit version in the wings, and the general public do not want to have to buy new versions of all the products they have or may be thinking of buying. Hence the JV announcement to try to bolster sales.

 

the current version of P3D is not as solid as FSX with DX10 and that is a fact it is OK for puddle jumpers but the big stuff doesnt work well and as hard as LM might be working to improve memory usage and VAS you cant make a silk purse out off a sows ear.

 

the future of our hobby and too many here forget it is a hobby, is 64 bit

No 64 bit, no future

Not mentioned here is that many fail to understand that more VAS will usually always means worsened performance, a certainty on poor computers. Finding a way to get around an error which actually provides an artificial preventative limit to burning your sim into FPS meltdown seems counter-productive to me.

 

For me it's far better to forget about 64bit and find a way to maximize quality whilst improving performance through more efficient handling of the simulator environment. That has always been a far larger problem than some error we can all very easily avoid through a little careful thought.. This would also benefit every single customer as opposed to the hardcore tweaking simmer who wants 4096x4096 textures across the board.

 

It really would not surprise me if the second we went 64bit, these forums would be awash with people complaining of poor performance as their computers are strained even further beyond what is possible now thanks to the OOM error.

Maybe the feature for using external vas like aerosoft said could be the best solution for every flightsim developer and user.

Maybe the feature for using external vas like aerosoft said

 

Have you got a link to this Aersoft announcement? I've seen a couple of people mention that they're working on some external tech but I haven't found anything about it. It's something to do with Airports right? I'm having a hard time figuring out how they could improve VAS externally