Questions from a prospective Open Rails User..

[scfe_fan]

Ok guys, I'm really liking what I'm seeing from the people who are using open rails... Can somebody or multiple somebodies give me all the info on OpenRails? I want to know all the good points, what is still being worked on, what it works with, & what I need to run it... Thanks,


Josh

[kox]

working (in v360):
-msts content load
-graphics
-multi core usage
-gpu usage
-switches
-lights
-activities
-sounds

not working yet (maybe they are now but just the developers see it):
-signals
-full traction physics
-multiplayer
-animations (exept bogies and wheels)

[OTTODAD]

A new beta is due at the end of this month and installing it will tell you all you want to know about what it can do to date with more to come !

O t t o

[longiron]

Ok guys, what I need to run it... Thanks,
Josh

Josh,

Open Rails requires:

- MSTS installation
- .NET Framework 3.5 SP1 Redistributable installed
http://www.microsoft.com/downloads/e...displaylang=en
- XNA Framework 3.1 Redistributable installed
http://www.microsoft.com/downloads/e...displaylang=en
- Open Rails software installed

http://openrails.org/release.html

Unzip the Open Rails software into a folder, point Open Rails to your MSTS installation, if it cannot find it automatically, and you're done!

[SurvivorSean]

Still in development.

For some people it already does plenty for what they want in a simulator. Others is a good look see and a glimpse into the future.

Regardless, well worth the download to check it out yourself.

Thanks

Sean

[muskokaandtahoe]

Off the top of my head rather than a comprehensive list:

What's obviously good: Visually correct on a wide-screen monitor; Pushes a lot of work from CPU to GPU resulting in overall performance gains all other things equal; Displays is all resolutions; Reads and displays MSTS content w/o needing to change anything (tho OR can be more picky about stuff in .eng and .wags being coded correctly, stuff that MSTS simply ignored); Uses Direct-X 9 whereas MSTS used 7. 9 simply looks better; Real nice day and night skies: sunlight and dynamic shadows.

What's subtly better: uses Davis curves for resistance; coupler buff & slack forces; Multi-threaded provides add'l performance gains w/ multi-core CPU's and Win 7.

What's incomplete as of V360: No distant mountains; no functional inter-actives (e.g., signals, crossing gates, etc.); no decals; missing cab views; No editor.

[OTTODAD]

No editor.

That can wait until ORTS is good enough to be used in preference to any of the other existing train simulators.

O t t o

[scfe_fan]

Thanks guys that really helps! Two more questions for now though... What does it have in terms of weather, weather effects, etc.. Does it run separately from MSTS or does it run inside MSTS?

[ericmp]

Open Rails runs independently of MSTS. As for weather, ORTS supports running in all four seasons. In addition, you can change the weather type (clear, rain, or snow), and even adjust the amount of cloud cover in game.

[longiron]

Thanks guys that really helps! Two more questions for now though... What does it have in terms of weather, weather effects, etc.. Does it run separately from MSTS or does it run inside MSTS?

Open Rails is a brand new game engine (graphics display, 3D environment, special effects, physics, etc) that reads your MSTS routes, trainsets, activities, paths, and services. You actually don't need the "train.exe" file from MSTS for Open Rails to work. It's entirely separate from MSTS game engine. Hope this clarifies what Open Rails is and isn't.

[eric]

The only dependency (and I use that term loosely) is for MSTS/Kuju created *CONTENT* be available *IF* a particular route requires it.

You could (very easily actually...) create a route using only custom/third-party shapes/textures/tracks, and not require MSTS being installed.

[lindsayts]

What's subtly better: uses Davis curves for resistance; coupler buff & slack forces; Multi-threaded provides add'l performance gains w/ multi-core CPU's and Win 7.

The above impies multi-core does not work on Win XP (I use XP service pack2) this is not correct. Plenty of tests I have done indicate OR in XP will normall use between 2 to three cores most of the time, with I may say a major improvement in frame rate.

Also from my expierence OR does require a fair bit of steam to run. A slower 4 core machine doing a better job than a somewhat faster 2 core. I have neither machine in this form now but the slower was a Intel D975XBX2 MB with a Q4400. The 2 core is a Gigabyte P35 DSO3 with a Duo core 8600 (I think).This latter machine now has a somewhat slower clock speed quad core in it (a Q6600). This CPU replacement significantly improving OR.

[muskokaandtahoe]

The above impies multi-core does not work on Win XP (I use XP service pack2) this is not correct. Plenty of tests I have done indicate OR in XP will normall use between 2 to three cores most of the time, with I may say a major improvement in frame rate.

True.

I should have written with more thought to being clear. The issue is that the OS determines what to do with those cores, not the application. Windows 7 does a much better job than does XP. In my testing with both operating systems I had many occasions where it was very clear that XP had chosen to use only one core, not both, and that fps suffered as a result. I have not seen that occur with Win 7 and so it's my opinion that you'll see, on average, better utilization of multiple cores on a Win 7 machine than you would on an identical XP machine... and that will translate into better performace.

[conrail1]

The above impies multi-core does not work on Win XP (I use XP service pack2) this is not correct. Plenty of tests I have done indicate OR in XP will normall use between 2 to three cores most of the time, with I may say a major improvement in frame rate.

Here is some info taken from a hardware forum that discusses multi-core support in XP.

What it really boils down to is the application and whether or not it is written to take advantage of multiple cores.

“One small bit for clarity's sake: "Cores" generally refers to a physical processor. So "Multicore" means a single processor with multiple physical cores. "Multi~Processor" refers to more than one physical processor, each of which can have more than one 'Core'.

"Threads" generally refers to the software side of the house. "Hyperthreading" is a(n Intel) hardware term for a processor that's able to run more than one thread on a single physical core. When we say "Single Threaded" - that generally refers to a piece of software that has a single, linear process: it goes from A, to b, to c, to d... each in it's turn. "Multithreading" refers to code that's written to run pieces of itself, at the same time, in more than one physical or virtual "place", as well as the ability for a multi~core or Hyperthread~supporting processor's ability to support that.


Apologies to our more technical bretheren for the gross over simplification.


Now, to answer your question: XP can, and does, understand Multiple Cores and does support software that can run multiple threads. So if your program is written to use multiple threads, then it will do so on an XP machine. The limitation(s) are that the software you are running has to do so as well, or the software will only run in one place at a time. This means that - Even when your hardware and your OS support Multi-threaded apps, that does not magically change the app itself. If your (Game) is single threaded, then it can/will only run in a single threaded mode.

If you want a single application to use all 4 cores at once: (1) The Hardware has to support it. If yes, step (2) is that your OS has to support that. If (1) and (2) are Yes, then (3) your application also has to be written to support it.


Vista, as much as it's lambasted, is a little bit more efficient than XP in a Multi~Core/Multi~Thread environment. XP tends to load a single core before reaching out to utilize others. Vista generally tries to spread the load more evenly. (By server side standards, neither is particularly great since the default is what it is and their load balancing behavior can't have it's rules changed. But for the desktop, it's certainly adequate.) Anyways, in both cases a demanding, single treaded app can/will take near exclusive use of a particular core. The advantage is that, even when running only single threaded apps in a multi core environment, your OS can choose to run multiple apps on the multiple cores which are available. (Hint: even when *you* are only running one app at a time, your computer is still running a laundry list of processes.)


Regardless, the short answer is "Yes, your XP machine can utilize all 4 cores".






{Edit for the techies to provide data on the assertion that multithreading was improved in Vista} Source: http://developer.amd.com/documenta [...] 3.aspx#two
Quote :
The Incremental Improvements Within Vista

The incremental improvements within the OS relating to multicore performance include enhanced support for nonuniform memory architecture (NUMA) systems (such as the AMD Opteron™ family), pervasive prefetching (at both the low level of dealing with page faults, and the system cache read-ahead and the Prefetch/SuperFetch user-feature, which loads oft-used programs in anticipation of user launch), improvements to internally-used data structures and algorithms, an improved DLL loader that creates processes significantly faster, and a much-improved thread pool.

The thread-pool changes include generally improved performance and the ability to support multiple pools per process. This seems a good time to mention Vista's system-wide anti-convoy features. A "lock convoy" is a situation where performance tanks because a large number of threads are blocked, waiting for a resource, and when the resource becomes available, every thread is awoken, all but one fails to acquire the resource, and all but one are set back to waiting. When the number of threads is high enough and the work performed per thread is small, the time spent in overhead can overwhelm the amount of time spent working. That lock convoys arise from attempts to make thread scheduling "fair" is just one of those surprising results that turns concurrent programming into such a challenge.

Vista uses a different lock handoff mechanism that's "unfair," in that there's now a race condition between a lock becoming available and its acquisition by the first thread in the wait list. This makes it possible for a thread to "sneak in" and grab the lock sending the should-have-been-scheduled thread to the back of the wait list (and at least theoretically raising the potential of starvation). Lock convoys were, anecdotally at least, often the root problem of system-wide freezes that lasted for several seconds and then disappeared.”

Here’s some info on multi-core performance on XP, Vista and Windows 7 -

http://www.infoworld.com/t/platforms/generation-gap-windows-multicore-273?page=0,0