Time for an official 64-bit version ?

[mstsbe]

Some folks at Activitysimulatorworld have already been playing with some compilation flags or 3rd-party utilities to make OR large-address aware, but I consider these solutions rather poor. They did this because they noticed some routes in urban areas and cities are using already 2 GB RAM or more, and wanted to use as much memory as possible to prevent a OutOfMemory exception.

http://forum.activitysimulatorworld.net/viewtopic.php?f=102&t=22086

http://www.elvastower.com/forums/ind...-than-2gb-ram/

The problem is that the XNA Framework is 32-bit only, and Microsoft ditched it all before even trying a port to x64. On UKTrainsim twpol once wrote that the XNA code they use is mainly boilerplate code, and could be replace quite easily by native DirectX code.

http://forums.uktrainsim.com/viewtopic.php?f=324&t=111008&p=1383944#p1384043

Once we go 64-bit however, XP compatibility will have to be dropped. XP only supports up to DirectX 9.0c, and XP 64-bit was a terrible release to get anything working on, so this shouldn't be much of a problem. Most commercial games which have gone 64-bit also require DirectX 10 (which implies at least Vista 64 or Win 7 64).

For now it would be best that development of the 64-bit version will be started with basic functions available (i.e. same features as around v645). Next versions will then contain more and more code from the release version, but rewritten to be 64-bit compatible. Development of the normal version should continue as planned, and once v1.0 is released development of the 64-bit version should be accelerated so that both versions will eventually have the same functionality. From v1.1 onwards, both versions should be developed concurrently, up to a point when Microsoft discontinues support for x86 operating systems altogether.

[conrail1]

Some folks at Activitysimulatorworld have already been playing with some compilation flags or 3rd-party utilities to make OR large-address aware, but I consider these solutions rather poor. They did this because they noticed some routes in urban areas and cities are using already 2 GB RAM or more, and wanted to use as much memory as possible to prevent a OutOfMemory exception.

http://forum.activitysimulatorworld.net/viewtopic.php?f=102&t=22086

http://www.elvastower.com/forums/ind...-than-2gb-ram/

The problem is that the XNA Framework is 32-bit only, and Microsoft ditched it all before even trying a port to x64. On UKTrainsim twpol once wrote that the XNA code they use is mainly boilerplate code, and could be replace quite easily by native DirectX code.

http://forums.uktrainsim.com/viewtopic.php?f=324&t=111008&p=1383944#p1384043

Once we go 64-bit however, XP compatibility will have to be dropped. XP only supports up to DirectX 9.0c, and XP 64-bit was a terrible release to get anything working on, so this shouldn't be much of a problem. Most commercial games which have gone 64-bit also require DirectX 10 (which implies at least Vista 64 or Win 7 64).

For now it would be best that development of the 64-bit version will be started with basic functions available (i.e. same features as around v645). Next versions will then contain more and more code from the release version, but rewritten to be 64-bit compatible. Development of the normal version should continue as planned, and once v1.0 is released development of the 64-bit version should be accelerated so that both versions will eventually have the same functionality. From v1.1 onwards, both versions should be developed concurrently, up to a point when Microsoft discontinues support for x86 operating systems altogether.

It's been brought up before, here's one discussion from a year ago, take a look at the responses in this thread (pages 3-6) -

http://www.elvastower.com/forums/ind...s/page__st__20



XNA, a dead end street -

https://www.trainsim.com/vbts/showthread.php?313199-XNA-is-being-killed-off

[seagoon]

Does this mean that the Open Rails of the future won't run on my system?

[rdamurphy]

First, the Open Rails Development team is fully aware that XNA is not being supported or updated further by Microsoft. And there is an effort to find a viable alternative, that isn't costly, and doesn't require massive amounts of code revision. It's highly doubtful any change will be made until after 1.0 is released. Currently, there are updates to the code, not just on a daily basis, but sometimes several times a day. To change over would require all development to come to a halt until the code was converted. However, OR has changed the way it interacts with XNA to make it easier to move away from it in the future.

Secondly, the Open Rails Development team currently uses Visual Studio.net 2010, and there is no 64 bit version available.

There has been discussion towards moving forward to a newer version, but in order to do that, the entire development team has to change over at the same time. Code cannot be managed with different versions of .net...

Currently, Open Rails is a Windows-only application, and again, it has been discussed moving to a multi-platform solution, but again, that would not be possible with .net. So, for the foreseeable future, OR will continue to work on Windows.

I hope that answers your questions!

Thanks,

Robert

[conrail1]

To change over would require all development to come to a halt until the code was converted.

Just one of the reasons why many of us warned about not getting to cozy with MS XNA Framework to begin with, 3-4 years ago. Using OpenGL (which was also suggested years ago) would have been a good way to go from the start.

[mikeebb]

There are 2 points being made here, I think, that are getting confused.

1) 64-bit. This is the ultimate solution, but appears to break everything.
2) Large Address Aware. This is not just a hack. MS supports it. A LAA 32-bit program has 3-4 GB of address space available (depending on hardware and driver usage) in a 64-bit system with adequate (more than 4GB) memory. OR is probably already Large Address Aware - that's been standard since early Vista releases of VS. If those test cases have gone over 2GB without crashing, that's proof. I hate to sound like Bill Gates (...640K is all anybody will ever need...) but in this case, in the short term, 4 GB is probably all people WILL need for OR. At least until OR-specific routes with far more complexity and eye candy than MSTS can handle become common.

-mike b (just observing, most of the time)

[conrail1]

1) 64-bit. This is the ultimate solution, but appears to break everything.

Over the last two years a couple of sims I run (X-Plane 10 and iRacing) both moved over to 64-bit. Neither sim had any serious issues in doing so, it all goes back to whether or not the developer knows what they are doing or not.

In the case of OpenRails when you are dependent on volunteers who are working for free in their spare time it's not going to be an easy task. The same can be said for switching gears entirely with a new game engine which is most likely the reason why XNA Framework was used to begin with.

[mikeebb]

I understand the issue with development by volunteers. I'm grateful that OR has made it as far as it has.

If one of the issues is use of XNA, I'm sure somebody else has already mentioned http://www.monogame.net/ (XNA4 clone for multiple platforms).

[seagoon]

Just one of the reasons why many of us warned about not getting to cozy with MS XNA Framework to begin with, 3-4 years ago. Using OpenGL (which was also suggested years ago) would have been a good way to go from the start.

It's so easy to be wise with the benefit of hindsight.

Here's an idea; let's keep putting-off doing things just in case technology changes!

[conrail1]

It's so easy to be wise with the benefit of hindsight.

What hindsight?, take a look at the dates in some of the discussions in the links given.

Oops I forgot, I must have just got done looking into my crystal ball before response #6 in this thread back in 2010 -

https://www.trainsim.com/vbts/showthread.php?297760-Present-ORTS-limitations

Here's an idea; let's keep putting-off doing things just in case technology changes!

I've got a better one; how about doing some real research to find out what the best tool for job is!

[twpol]

Once we go 64-bit however, XP compatibility will have to be dropped. XP only supports up to DirectX 9.0c, and XP 64-bit was a terrible release to get anything working on, so this shouldn't be much of a problem.

That's not how .NET applications work. They can compile to 'AnyCPU' which will take advantage of 64bit on a 64bit OS but still run on a 32bit OS (just in 32bit). Additionally, both SlimDX and SharpDX (two good candidates to replace XNA) support DirectX 9 on Windows XP and 'AnyCPU' compilation - so this is actually possible.

For now it would be best that development of the 64-bit version will be started with basic functions available (i.e. same features as around v645). Next versions will then contain more and more code from the release version, but rewritten to be 64-bit compatible. Development of the normal version should continue as planned, and once v1.0 is released development of the 64-bit version should be accelerated so that both versions will eventually have the same functionality. From v1.1 onwards, both versions should be developed concurrently, up to a point when Microsoft discontinues support for x86 operating systems altogether.

There may be some confusion here. Our code, except for maybe a couple of OS-hooks, works absolutely fine in 64bit as-is. The problem here is the XNA library, which is 32bit-only. We would be rewriting code for a graphics library switch - not for 64bit.

In short, there are 3 things:

• Replace XNA with another library/API layer.
• Enable 64bit support. (This could still work on XP.)
• Switch to DirectX 10 or some later version. (This couldn't work on XP.)

We need to do the first thing before we can do either of the others, but they do not need to happen at the same time as each other or at the same time as the first item.

[OTTODAD]

What is the advantage of having a 64-bit version of ORTS, the 32-bit version working perfectly on my WIN-7 Pro 64-bit i5 computer ?

[rdamurphy]

What is the advantage of having a 64-bit version of ORTS, the 32-bit version working perfectly on my WIN-7 Pro 64-bit i5 computer ?

It might be slightly faster... Maybe. I'm usually over 100 fps anyway, even running it from VS.net in debug mode...

It will probably speed up eventually anyway, when 1.0 is released and all of the debugging stuff is taken out.

Robert

[OTTODAD]

It might be slightly faster... Maybe. I'm usually over 100 fps anyway, even running it from VS.net in debug mode...
It will probably speed up eventually anyway, when 1.0 is released and all of the debugging stuff is taken out.

With the current craze of using tablets I wonder how that will affect the running of games and simulators on laptops and desktop computers.

[conrail1]

It might be slightly faster... Maybe.

Moving to 64-bit has very little to do with performance -

http://developer.x-plane.com/2012/09/things-64-bit-will-not-do/

Things 64-Bit Will Not Do

Posted on September 25, 2012 by Ben Supnik

Chris and I wince whenever we see a forum post like this*:

Every time I start up the left engine of the KX-1000 turbojet, rain appears on my right windscreen.* I hope 64-bit fixes that!
Seriously though, 64-bit seems to have gained a reputation in the community as the messiah that will cure all evil.* This reputation is unfounded.

64-bit will do one and only one thing: allow X-Plane to use significantly more virtual memory without crashing.* If you crash because you run out of address space, 64-bit will help you.* It is not going to fix anything else.

Here are some things 64-bit will not do:

64-bit will not make X-Plane faster.* Using more memory doesn’t make things faster.* (Nerds: using IA64x86_64 doesn’t make things faster.* We’re not register bound because secretly x86 chips do crazy register renaming.* We are, however, L2 bound, and making all of our pointer-based structures 2x in size isn’t a move in the right direction.)* Past tests indicate that 64-bit is performance neutral.
It won’t fix any bugs.* If a system is broken in 32-bits, it will be equally broken in 64 bits.
It won’t make anything look any better.* The same settings should produce the same image in 32-bits or 64-bits.
It won’t bring world peace.* For that you need 128 bits.
Actually, that second-to-last statement is slightly not true . With 64 bits, some settings will become possible for some users that were strictly memory bound before.* For example, if you couldn’t run extreme texture res and extreme forests only due to memory limits, 64-bits will let you use extreme res and forests, and that probably will look better than having to pick one or the other.
Of course, with the address space limit removed, users will run into a series of new limitations:
Some users will run out of physical memory.* Fortunately RAM is very cheap, but it’s not easy to upgrade in a laptop or iMac.* (I stand corrected: apparently iMac RAM upgrades are now slip-in, which is cool.* I think a while ago you had to pop the case, which wasn’t much fun.* The TiBooks used to have a RAM drop-in under a pop-off keyboard, which was cool but put constraints on how strong the keyboard could be.* But I digress.)
Some users will not be able to show all of that extra 3-d “stuff” at reasonable framerates.
Some users will run out of VRAM at the higher texture resolutions.

There’s always one thing that limits performance…64 bit simply ensures that it isn’t the needless artificial limit of a 32-bit process.

I'm usually over 100 fps anyway, even running it from VS.net in debug mode...

You're over 100 fps with what route, at what resolution and image quality settings?