32bit Rulez!

[jcomm 5,886]

Truth being said, the two, actually 3 if we count PSX that can run as either 32 or 64 bit depending on the Java version one has installed, flight simulators that better fulfil my needs and wants as a simmer are indeed, still, 32 bit, and one is dx9, the other dx10...

 

I'm talking about FSX:SE, with the Fixer and dx10 mode active, and my pmdg 777, a2as and the realair legacy, plus asn, rex soft clouds, orbx ftx global and a single airport scenery by aerosoft ( madeira ), and the latest release of il2 battle of Stalingrad ( IL-2 BoS) released this week, and of course Aerowinx PSX...

 

In all aspects, ranging from the use I give to them, to the quality of flight dynamics, systems modelling, immersion, there simply is yet no 64 bit sim that reaches their level, or that I end up using that much, with the closest being DCS World, mostly because of the helicopters and it's ww2 fighters.

 

A simple circuit in my pmdg 777, or in the A2A Comanche or P51d Civil, or RealAir's Legacy, with weather masterly injected by ASN, in DX10 mode can't compare, that's the pure truth, with any experience I have had with other civilian sim.

 

When flight dynamics for powerful prop aircraft are my objective then, there simply is nothing comparable to a single mission, or a online combat in il2 BoS, although I start DCS World a few times too, but, it's not IMO up to the level of BoS, where the sophistication of the systems interaction is simplified, but the flight and overall physics really excel!

 

So, the three best sims I can say I ever used are still in the Golden Ages of flight simulation - the 32 bit Era!

[pracines 823]

I agree, we currently do have some very nice home based flight simulators to choose from, with the various add-ons we compile, they do a nice job. I mostly fly P3D V3 in planes ranging from the A2A Cub to the PMDG 777 and it works well for me.....I want/expect more :-) 

 

I will keep my eye on the upcoming titles that may end up being so much better than we currently have ----  http://nexgenflightsim.com/wordpress/ (64-bit no doubt), http://www.aerofly.com/aerofly_fs_2/, and http://www.dovetailgames.com/news/2015/aug/4/dovetail-games-looks-to-the-future-collaborating-with-microsoft 

 

I will remain skeptical, cautious, yet hopeful. I will not just shoot these possibilities down. Initially, I was under the impression that Aerofly 2 was going to be a geographically limited sim, but many insist that the whole globe is intended in the PC version. NexGen FS is said to have a whole earth highly detailed and be better than any thing we currently have in all aspects. Dovetail is keeping a tight lid on what we can expect, but they say that simmers and gamers will be pleased.

 

I wish all the best for these planned/intended upcoming titles.

[Christopher Low 5,331]

I can't comment on 64bit flight simulation, as I do not own X-Plane. However, the massive improvement in VAS management with P3D v3 has certainly extended the life of 32bit flight simulation on my PC by quite some margin!

[WotanUK 289]

It's an entirely irrelevant comparison.

 

If FSX had been 64-bit from the start we wouldn't be clambering for a 32-bit version to improve it.

 

It's the add-ons that make the sim good, these would have been produced if the sim was 64-bit.

[jcomm 5,886]

Ian,

 

I am, of course, not comparing apples to oranges, and that was not meant to be the message to pass, but simply assuming that after all the three sims that I my preferred, even now that we have a few 64 bit choices available, are still, 32 bit :-)

 

DCS World I consider to be the platform I currently put mu biggest expectation in, for the quality of their aircraft, specially the helicopters, and the huge improvements that v1.5 and soon EDGE will bring, but still, it is from FSX:SE and IL-2 BoS, and also PSX, that I take 80% of my simmer enjoyment, the remaining 20% being devided between RoF and DCS...

[Luke 782]

If FSX had been 64-bit from the start we wouldn't be clambering for a 32-bit version to improve it.

 

Given the (lack of) availability of 64-bit operating systems and processors in 2003, this would have been a breathtakingly poor move on Microsoft's part.

 

Cheers!

 

Luke

[Guest]

In 2006 64bit processors were majority market share ... it really should have happened in 2006 since FSX hit OOM very quickly even with no add-ons.  But I'm not sure why many thought that it would be impossible to have both a 32bit and 64bit FSX?  Many seem to think it's one or the other and can't be both -- I'm not sure why?

 

At the time the Aces' dev team was pretty large and that WAS the opportunity to start a 64bit path in addition to the existing 32bit path.  If you looked at the yearly sales figures for MS FS series it was clear the decline in numbers ... I don't think the closure was a surprise to many -- it wasn't for me and that's why I pushed so very hard (and I admit, way too hard) to get Phil Taylor to produce a 64bit path.

 

Applications (Games/Sims) drive hardware, they always have from day one of the PC ... why handicap a platform to the lowest common denominator, build a future and they will buy the hardware ... eventually.

 

Cheers, Rob.

[jcomm 5,886]

Rob,

 

let that first 128 bit sim be released :-)  I have  an HPC IBM Power 7 here at the Office!

[Luke 782]

 

In 2006 64bit processors were majority market share ..

 

Majority of processors sold? Sure. Majority of installed base? Maybe. Even then it doesn't matter - because you needed a 64-bit operating system (and more than 4GB of RAM - not strictly necessary, but if you didn't, why bother?) Hands up those of you running 64-bit XP with >4GB of RAM in 2006. It's such a small number it's probably a rounding error.

 

Windows 7 was the first version of Windows where 64-bit had the driver support and the hardware started taking advantage of 64-bit mode. Even in 2010 half of all Windows 7 installs were 32-bit (although I imagine corporate use skews this a fair bit.)

 

 

But I'm not sure why many thought that it would be impossible to have both a 32bit and 64bit FSX?  Many seem to think it's one or the other and can't be both -- I'm not sure why?

 

...

 

If you looked at the yearly sales figures for MS FS series it was clear the decline in numbers ... I don't think the closure was a surprise to many -- it wasn't for me and that's why I pushed so very hard (and I admit, way too hard) to get Phil Taylor to produce a 64bit path.

 

You answered your own question. How would a Product Manager with P&L responsibility in 2006 be able to justify doubling development and testing efforts to build a parallel version on a platform that hardly anyone used, or would seriously require for the next half decade? If memory usage was a concern, the logical step to do would be to work on minimizing VAS usage in the 32-bit version, akin to what L-M appears to have done with P3Dv3.

 

As well, look at the 16-bit to 32-bit conversion in 1995; Microsoft did not release parallel versions. They just built something for Windows95 - and what's interesting is that on that date, 32-bit processors had been sold in the marketplace for over a decade, but we didn't get a pure 32-bit version of consumer Windows until another half decade later.

 

Cheers!
 

Luke

[Guest]

Moving from a 32bit path to a 64bit does NOT require a complete write ... no need for two entirely separate development teams or doubled efforts, the code doesn't change that much.  In fact, I'd argue that MS might still be involved in the FS series today if they had released both a 32bit and 64bit FSX product.  Microsoft's plan for simple less complex product (aka MS Flight) was clearly not what the majority wanted ... and MS already had that in FSX.  It's the standard Microsoft executive/management disconnect with understanding consumer market and consumer desires.  FS has always been unique in that respective, it doesn't follow the traditional crank out a game that lasts 2 weeks and then on to the next game.

 

But doesn't really matter, most funders/PMs believe LCD is required to sell -- for 3D shooters I would agree, for flight simulators I would NOT agree.  

 

Cheers, Rob.

[Christopher Low 5,331]

Assetto Corsa is a good example of dual 32bit/64bit software. The 64bit version was added very recently, but there is a menu option to run in 32bit mode.

[Luke 782]

Moving from a 32bit path to a 64bit does NOT require a complete write ... no need for two entirely separate development teams or doubled efforts, the code doesn't change that much.

 

It's not as simple as you think, especially with a lower-level language like C that doesn't shield you from the assumptions of the underlying platform. I've had very few code bases that transitioned from 32-bit to 64-bit without issue - and all were written in languages that ran on a cross-platform VM: Java and Javascript. I have some C# code that I would love to port to 64-bit, except I can't make P/Invoke calls from a 64-bit image to a 32-bit DLL (the Level-D SDK) so 32-bit it stays.

 

While C is portable, it doesn't stay that way unless developers are very careful about platform assumptions. On FSX, which was developed only for Win32 over the course of over a decade? I wouldn't make that assumption at all. Just like the port to Win32 was probably filled with all sorts of pain eliminating the relics of what one could do in real mode DOS, I expect a 64-bit port would have to extricate a lot of platform assumptions. That's a lot of additional development and (especially) testing. X-Plane has an advantage here in that it's written for 3 different platforms which forces portability into everything.

 

A 64-bit port would either involve a similarly sized dev team porting to the new platform with no new features, or doubling the size of the team. QA would pretty much double simply because you have two platforms and two different code bases to validate. There's no getting around that.

 

MS refused to do a 64-bit port. L-M has invested significant resources in P3D and they too aren't rushing into a 64-bit port. There's a reason for that, beyond myopia or incompetence.

 

Cheers!

 

Luke

[Guest]

It's not as simple as you think, especially with a lower-level language like C that doesn't shield you from the assumptions of the underlying platform. I've had very few code bases that transitioned from 32-bit to 64-bit without issue - and all were written in languages that ran on a cross-platform VM: Java and Javascript. I have some C# code that I would love to port to 64-bit, except I can't make P/Invoke calls from a 64-bit image to a 32-bit DLL (the Level-D SDK) so 32-bit it stays.

 

....X-Plane has an advantage here in that it's written for 3 different platforms which forces portability into everything.

 

MS refused to do a 64-bit port. L-M has invested significant resources in P3D and they too aren't rushing into a 64-bit port. There's a reason for that, beyond myopia or incompetence.

 

Cheers!

 

Luke

 

Disagree ... P3D is actually C++ compile with VS 2013 and I'll guess that will move to VS 2015 in the future.  It's highly unlikely P3D use P/Invoke calls, there would be no reason to ... not to mention P/Invoke is not thread safe.

 

XPlane 10's portability is primarily due to the use of OpenGL, not because it's 64bit or 32bit.

 

But to answer your own question, XPlane moved from 32bit to 64bit with NO change in the size of the development team.  There is no reason the development needs to double just because of a invocation target change.  I never said it was "easy", I said it doesn't require double work efforts.  

 

The reasons LM isn't 64bit yet is:

 

1.  There was more to squeeze out of 32bit and get it efficient (which they've done, I can't OOM V3 now)

2.  3rd party compatibility

 

There is also the issue of making sure the 3rd party dev tools used by LM (SpeedTrees, Triton, etc.) have 64bit components that can be referenced.

 

Cheers, Rob.

[Luke 782]

P3D is actually C++ compile with VS 2013 and I'll guess that will move to VS 2015 in the future.  It's highly unlikely P3D use P/Invoke calls, there would be no reason to ... 

 

The reason I mention P/Invoke is not because they're using that specific method (it's not running in the CLR), but that they're making lots of Win32 API calls or calls to other external libraries. How many of those calls have been defined with the assumption of running on Win32 and won't safely port? I write for portability and I still find a lot of references to UInt32 when I meant IntPtr - but on a 32-bit platform it doesn't matter.

 

And whether it's C or C++, you can still do all sorts of fun things like pointer arithmetic and performance-specific enhancements that make assumptions about the platform its running on and the compiler defaults. Have you ever written something that was non-portable but 20% faster, knowing you'd never run on a second platform and you'd deal with it down the road? Corporate software development is full of short cuts, optimizations and "it compiles, move on" - and FSX is a code base with support for FS2000, FS2002 and FS2004 components. You'd better believe there's a ton of this stuff buried in the code base.

 

XPlane 10's portability is primarily due to the use of OpenGL, not because it's 64bit or 32bit. But to answer your own question, XPlane moved from 32bit to 64bit with NO change in the size of the development team. There is no reason the development needs to double just because of a invocation target change.  I never said it was "easy", I said it doesn't require double work efforts.  

 

I think you misunderstand my point. X-Plane could (relatively) easily move from 32 to 64 bits because they supported multiple platforms - they couldn't do anything in a platform-specific way and had to abstract it all away. Once you have that abstraction in place, you've paid the largest marginal cost because then going from 32 to 64 bits meant that XP was moving from three platforms to six. Every additional platform is cheaper to implement.

 

If you believe the marginal cost to go to a second platform isn't doubled, I'd be interested in hearing your thoughts and experiences on the subject. I concede it might be less than double over the long run as you build multi-platform experience, test cases and infrastructure. But when moving from one platform target to two, what is the additional spend you have to do in terms of resources to maintain similar feature velocity?

 

1.  There was more to squeeze out of 32bit and get it efficient (which they've done, I can't OOM V3 now)

2.  3rd party compatibility

 

There is also the issue of making sure the 3rd party dev tools used by LM (SpeedTrees, Triton, etc.) have 64bit components that can be referenced.

 

 

I don't understand your reasoning. If porting to 64-bit on top of the existing 32-bit code base was so easy, why would they go through a painful optimization exercise in a legacy code base? You're making changes and there's a significant likelihood of breaking things - it you can just recompile and make the VAS essentially unlimited, wouldn't that be the logical step to do? The fact that they went through such a risky exercise suggests that recompilation to the new target was even more expensive and time-consuming.

 

I understand the 3rd party compatibility (the gauges would all break; they are essentially DLLs IIRC) but we're not talking about a platform move like we did with FS95; it's just an additional platform so one would still have a 32-bit platform where everything would continue to function as before. Same things with dev tools - you don't need 64-bit dev tools to create data artifacts for a 64-bit simulator.

 

I remain pretty certain that the development and validation efforts for a 64-bit port are substantial. They are probably justified today but could not have been a decade ago. If you've ported a large legacy C++ code base from Win32 to Win64 (which, admittedly, I have not) I'd be very interested in hearing your experiences in why it's a lot easier than I expect it would be.

 

Cheers!

 

Luke

[Guest]

Hey Luke,

 

Please re-read what I said, specifically this ...

 

"I never said it was "easy", I said it doesn't require double work efforts."

 

There is actually a limit to 64bit ... about 16TB.

 

Going back to 2006 with this info ... and was available to Ace's too  https://technet.microsoft.com/en-us/library/bb496995.aspx  to quote this article:

 

 

 

Comparison of Win32 and Win64

This section compares the major differences between the Win32 and Win64 APIs:

• Data model. The Win64 data model is almost the same as that of Win32. However, new data types and pointers have been added. In the ILP32 data model (of Win32), integer, long, and pointer data types are 32 bits, whereas in the LLP64 (or P64) data model, the pointer data type is 64 bits.

  Note   You need to look at the sections of code where integer, long, and pointer are used interchangeably. Such code would work in Win32 but cause major issues in Win64, and you might face issues when migrating a UNIX 32-bit application to a Windows 64-bit environment.

• Environment. The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.

  The Windows header files are modified so that you can use them for both 32-bit and 64-bit code. The new 64-bit types and macros are defined in a new header file, Basetsd.h, which is present in the set of header files included by Windows.h.

  The Basetsd.h file includes the following:

  • New data-type definitions that you can use to make your application word-size independent.

  • Many helper functions for conversion such as:

    unsigned long HandleToUlong (const void *h)long HandleToLong (const void *h)void *LongToHandle (const long h)unsigned long PtrToUlong (const void *p)unsigned int PtrToUint (const void *p) 

• Data types. There are three categories of new data types that are supported on 64-bit Windows: fixed-precision data types, pointer-precision types, and specific-precision pointers.

 

There are many ways to move to a 64bit path ... but if the primary goal is to extend VAS then we're really just talking about texture array allocations and the quad-tree size ... think about how quickly Laminar Research moved from 32bit to 64bit.  I can't think of any reason an actual 64bit data type is needed?  I think you'll find the task not as daunting as you think ... not easy either, but certainly doable with a small development team provided the dev tools being leveraged (Triton, SpeedTrees, etc.) have 64bit components ... even more doable with LM's larger development team.

 

Any 3rd party that builds to a DLL will need to build to a 64bit one, it many cases that'll probably be pretty easy.

 

Cheers, Rob.