[disc]

 wacampbell, on 22 October 2013 - 12:11 PM, said:

It seems a majority of the Linux community are hostile to windows and paranoid that Microsoft exec's spend their every waking day plotting its demise.

OFF
Yes the most of the linux community are hostile to windows... and not just the linux community. That's because microsoft is hostile to everyone(and because they probably tried every operating systems and used them not just for few minutes), and their history is just about doing dirty tricks to lock users to their more or less inferior platform/applications, and to make migration hard or impossible. These are not paranoid fantasies, but based on facts. When direct3d was made, openGL existed already, but microsoft didn't want to use that as it is multiplatform, so they've made the inferior direct3d, and helped to spread it by money (paying to big game developers to use it instead of other 3D libraries.
Or see microsoft's own HTML "standard" for internet explorer 6, which served the total incompatibility with others, and locked the users to that browser for years, and made hard time for web developers. Or see the attempt to make and spread their own modified Java, the MS Java, which was like the IE6's html, targeting the incompatibility. It was ceased after Sun sued MS and made microsoft to copy the idea of Java, which lead to .NET and C# :) Or see their own document formats, that can be read perfectly, only by microsoft softwares. Or the attempt to make a windows locked "Flash", the silverlight, and this shows their unreliable directives. Few years ago they said "silverlight is the future, silverlight is the best", then few years later, boom "sorry guys the development of silverlight will be ceased, use HTML5 and javascript instead").
/OFF

[Simon E]

 James Ross, on 06 October 2013 - 09:57 AM, said:

It is my belief that, as long as DirectX 9 and .NET exist on the desktop, we'll be fine with the current XNA 3.1 platform. That should be quite a few Windows versions yet.

We're not going to keep using XNA until we can't, however. There has been experimental work to use XNA 4.0 (different API to 3.1, and one that's supported by a number of non-XNA platforms), ANX, DirectX through SharpDX and SlimDX and even MonoGame to name just a few.

It is worth noting that XNA, as we're using it, does not actually provide very much functionality - it is almost exclusively a thin wrapper on DirectX (similar to SharpDX/SlimDX). That is positive, because it means we're only really tied to DirectX, and if that disappears there'll be more problems than just Open Rails. :mshk:

Just recently, in X.1733, we got rid of the XNA Content Project, which tied up the development environment to XNA (Visual Studio/Express 2008) so we're now pretty much free to use any version of Visual Studio (still a few minor kinks).

Replacing XNA is naturally a big project, but we've got options - quite a few of them. :)

I am so glad to hear this. Maybe we can make a "game engine" that is especially geared and optimised towards Railway and Tramway Simulations?

Going 64-Bit would be a good investment. Even the ability to port to other platforms (Mac, Linux etc, as well)

[Simon E]

 James Ross, on 06 October 2013 - 09:57 AM, said:

It is my belief that, as long as DirectX 9 and .NET exist on the desktop, we'll be fine with the current XNA 3.1 platform. That should be quite a few Windows versions yet.

We're not going to keep using XNA until we can't, however. There has been experimental work to use XNA 4.0 (different API to 3.1, and one that's supported by a number of non-XNA platforms), ANX, DirectX through SharpDX and SlimDX and even MonoGame to name just a few.

It is worth noting that XNA, as we're using it, does not actually provide very much functionality - it is almost exclusively a thin wrapper on DirectX (similar to SharpDX/SlimDX). That is positive, because it means we're only really tied to DirectX, and if that disappears there'll be more problems than just Open Rails. :mshk:

Just recently, in X.1733, we got rid of the XNA Content Project, which tied up the development environment to XNA (Visual Studio/Express 2008) so we're now pretty much free to use any version of Visual Studio (still a few minor kinks).

Replacing XNA is naturally a big project, but we've got options - quite a few of them. :)

Yes! I did not think we would be DERAILED by this. And I hope it is not so.

Does this means I can use Visual Studio 2013 and other 3rd party free code to "experiment" with svn ORTS code?

I am not going to do anymore experiments, until I know this Information, I Still use Visual Studio 2008. As some of my projects are still in this IDE. I Do want to upgrade to VS 2013.

Maybe make ORTS 64-Bit. Maybe even Mac Compatible too. I have a few Ideas for this, I have examined the Source Code of ORTS in Detail. It is very interesting, when you are not driving a train in it, and run out of RAM.

I have 8GB of RAM. And I am 64-Bit capable too.

When I know more about XNA's "fate" I will happily join The ORTS Developer team. I have bookmarked the page on where to do so.

Also what are the "minor kinks" that are involved? I might be able to solve them…. I have a feeling as to what they might be, from looking at code. I also know a lot about EMU trains. (that is Electric Multiple Unit trains, for those who don't know Railroad Jargon, Never to mind computer Science stuff.

Simon.

[Serana]

Before working on localization and TCS scripts, I did some tests. I tried to convert OR to XNA4 or MonoGame.
I managed to making it work mostly.
There's two main things that are problems with no fixes because Microsoft removed a feature.

Firstly, the transfers are no longer working because Microsoft removed TextureAddressMode.Border. The only solution is to reimplement it in MonoGame. It will be easy for DirectX, but there will be a bit of work to be done for OpenGL.

Secondly, the precipitations are no longer working because Microsoft removed Point Sprite support. The solution would be to reimplement it completely using 3D triangles. I saw implementations that looked even more realistic than current OR implementation.

Overall, in MonoGame, many functions have not been totally implemented : some functions are defined for a type of parameter, but not for others.

For 64 bit support, the problem is that XNA has only been compiled for 32 bit computers. There's a trick to support 4 gigs of RAM on 64 bit computers (using editbin program to put a LargeAddressAware flag on RunActivity, which I managed to integrate to my build process).
But if we convert OR to MonoGame, DirectX, OpenGL or SharpDX, this limitation will disappear since it is possible to compile those libraries in 64 bit mode.
To be honest, I never needed more than 2.5 gigs for very heavy routes. The use of editbin is enough for now.

A way to do the conversion smoothly would be to put all of the XNA-specific code into a plug-in. Then develop an OpenGL, DirectX or SharpDX plug-in. We would have to design an interface between the main program and the graphics plug-in.