Solution to a problem

[RavenHawk]

I have been gettin aquanted with this simulator and find it very interesting. After see all the hate on the forum about graphics bugs and what not I had decided to see what was the root cause of this issues that many are having. As such I had started with only the bare minums and starte form there.

1. Graphics cards are a big issue with this game and I see that many are dealing with driver issues. I have a nvida gt640 with 4 gigs of ram. Some tuttering but on medium settimngs all is well.

2. cpu. I will not even try to deal with this as I have completeley lost all hope of what is or is not provalent at this time. I have a amd Athlon 2 x3 3.2 processor.

3. Last Ram: The mor eyou have the more you can go.

[Rudolf Jan]

Seems a good strategy. You can turn up some things for not so demanding routes, Even with lower graphics settings there is a lot to enjoy.

[dwtrains_nz]

Agreed, its really not all that bad on medium settings, keeps the frame rate up too. I mean hell I've got TS running on medium settings on a Toshiba Satellite laptop with an amd radeon r7 with 4gb of ram, and I only have a Intel i7 x4 2.4 processor. Just proves you don't need out of this world specs to run this.

[Budge4]

As well as my own system that runs TS pretty good at 3840x2160 res (2 Titan X's and a 4790k cpu (4.4ghz turbo), M.2 pcie ssd, 32gb system ram). I still run TS on my girlfriends old comp as well. Q9650 quad cpu (3ghz, 2008 cpu), AMD 1gb 6790 graphics card, 8gb ddr2 system ram, normal h/d and an old 1280x1024 monitor, all years old. It runs TS fine with dynamic lighting\clouds turned on.

Just have to lower some of the other graphics settings a bit. But still looks ok and plays ok, If you dont set your sights to high with the settings then TS is pretty playable on some quite old hardware, let alone the new stuff.

[simonmd]

I don't know about 'hate', some of us get frustrated sometimes sure but the root cause to the 'problem' you mentioned is simple, this game is 6 years out of date and runs on 32bit software. No amount of hardware tweaks will fix that.

[Axe]

I thought this game could only use a maximum of 4GB memory so upping the memory would appear to be a misnomer.

I get 25-30 fps with all the graphics on full with 8GB Ram a GTX 770 4GB and a i7 4770 with harldy any stuttering.

It's fine for me.

[Budge4]

There are some routes ive seen in the past that recommended 8gb Axe, look at bottom of pages below for the system specs, ive seen other routes that recommended 8gb as well. So TS is either using 64bit exe or at least has the Large Memory Address Switch enabled. So obviously you need a 64bit OS to use 8gb, maybe the route is very borderline memorywise with 4gb ram and using 64 bit OS with 8gb just gives it a bit more headroom.

But there is definately a few routes that recommend 8gb ram.

http://en.shop.aerosoft.com/eshop.php?action=article_detail&s_supplier_aid=50756&s_design=bahn&shopfilter_category=Train%20Simulation&s_language=english

This one says 4gb ram but recommends 8gb -
http://en.shop.aerosoft.com/eshop.php?action=article_detail&s_supplier_aid=50283&s_design=bahn&shopfilter_category=Train%20Simulation&s_language=english

If your using a 32bit OS you obviously cant use 8gb ram.

Even if TS is 32 bit, having a 64bit OS and 8gb ram must give TS some extra headroom to maneuver somehow.

[Axe]

Ah. Interesting stuff. Thanks for the info Budge.

[simonmd]

Originally posted by Budge4:

...So obviously you need a 64bit OS to use 8gb, maybe the route is very borderline memorywise with 4gb ram and using 64 bit OS with 8gb just gives it a bit more headroom.

But there is definately a few routes that recommend 8gb ram. .

Exactly, They want to ensure the user has enough total system resources ad TS will need the full 4gb and any pc still needs a couple of GB or more to run Windows and other background programs like antivirus and of course Steam itself as well.

[RavenHawk]

One of theses days we will have a computer that will have over a terebyte of ram a processor that eats terrorist for luch and turns them into rivits and virtual reality like we have nver seen before, minus the porn of course.

[simonmd]

And thats when DTG will finally release the UR4 engined TS....

[OldAlaskaGuy]

So many people have upgraded and overbuilt just to play this sim smoothly that when UR4 arrives it will be in 3D and totally awesome with full imersion.

[Phase3]

There is an awful lot of misinformation in this post.
First lets look at the RAM issue yes as a 32-bit app TS2016 can address UP TO 4GB - if it tried to use more than that - BSOD everytime. Now thge reason that 8GB is recommended for some routes - remember TS2016 can address up to 4GB PLUS the OS (64-bit) uses between 2G and 2.5GB - so now we need 6.5GB RAM installed and the nearest to that is 8GB.

The issue with a 32-bit app like TS2015 is NOT RAM but it is due to the Virtual Address Space:
TS 2016 and VAS

Every program that uses Windows as the OS is loaded into a Virtual Address Space (VAS) this is to protect windows and also to load the program (working set) into the cpu/RAM. It has NOTHING to do with the Physical RAM installed. The size of the VAS in either a 32-bit OS or a 64-bit OS running a 32-bit app (with large address aware flag set) like TS 2016 is 4GB maximum - it cannot be altered.

Now in a 64-bit OS the whole 4GB is allocated to TS 2016 (minor impact of video card) and the system/kernel/the 64-bit OS gets up to 8 terabytes of VAS all to itself.

When TS20xx becomes 64-bit, and the code is written correctly it will access up to 8 TERABYTES of VAS and we should never ever see a dump file again.

The problem in TS2016 is that (particularly the editor) that as the game runs and you just run scenario after scenario the contiguous space in VAS becomes smaller and the VAS itself becomes highly fragmented. Now when this reaches a critical level, TS 2016 will crash and create a dump file. If the code for a scenario, route, reskin, etc is written poorly – you may get a memory mismatch Cx0000005 error. All this means is that the OS has loaded the code into the VAS but has yet to load it into the cpu/RAM – the code “can’t be found” – error and crash.

If there were a RAM issue in TS2016 – WINDOWS would tell YOU to turn down settings and run very slowly and/or crash with a BSOD.

When I carried out a survey of 500 posts “complaining” about TS2013, 85% were due to the simmers themselves. Poor hardware, poor software, poor computer maintenance and so on. About 2% were steam issues and around only 3% directly attributable to TS2013.

Unless you have a top of the line late model AMD cpu, matched mobo, and high end video card these PCs will always struggle against their intel/nvidia counterparts. Read the FSX forums if you don’t believe me. AMD makes excellent business computers but if you think that an $80 cpu can perform as well as a $300 one then you have made the discovery of the century.

TS2016 needs a balanced well maintained computer – otherwise you will be posting here. I myself have run a cache verification since TS 2012 and I have 180GB of TS 2016 DLC.

So, the bottom line is that because Ts2016 is a 32-bit app the 4GB of VAS it utilises becomes very important, and that will be the cause of ,ost errors.


Simmers say that TS2016 is “old” code. Well when it was first developed there were virtually no multicore, multithreaded PCs, no DDR3 dual channel RAM, no SATA, no USB 3.0., no PCIE3 and so on and yet when you get it right it runs flawlessly on a modern PC. Why – because the code HAS been updated, over and over again, and since TS2012 it has been multicore capable. Sure its not UE4 standard but its as good as the other 32-bit engine simmers still on the market. Compare it visually and performance wise to MSTS to see what I mean.

[Axe]

Oo err missus!

[Phase3]

This is the technical explanation for the VAS:
It is a difficult concept to understand. It has NOTHING to do how much Physical RAM you have onboard.
The Virtual Address Space (VAS) is part of the Windows OS - in the first versions of windows if a piece of software crashed it crashed the whole of windows the dreaded BSOD. So to protect Windows it now loads all software into the VAS so if the program crashes it does not usually crash Windows as well.

Using say Win XP 32-bit loading an app like TS2014 (with the Large Adress Aware Flag set) will have a MAXIMUM of 4 GB of VAS to load into. This was an enormous figure 20 years ago when the usual PHYSICAL RAM was <1GB
However in a 32-bit OS 2GB of this VAS is allocated to the system leaving only 2 GB available for TS 2014 MINUS the VRAM on the videocard, so if you a video card with 1GB of VRAM it can nearly exhaust all of the VAS before you have even loaded TS2014.

The workaround was to usee the /3GB switch /userva = 2560 (via the boot.ini) which can increase the VAS up to 3GB minus the VRAM.

In a 64-bit OS, TS2012 gets a whole 4GB of VAS to itself and this is not impacted significantly by the VRAM. In a 64-bit OS like Win 7 - it can load into 8 TERAbytes of VAS and so has little impact on TS2014.

Now when you are editing in TS2014 you need plenty of VAS to carry out the edit commands - BUT in Win XP 32-bit you have only around 1GB VAS to play with and soon you will deplete this and a SBHH will follow as night follows day.

You think you are safe in a 64-bit OS where TS2014 gets a whole 4GB of VAS but maybe not so safe after all. As you edit the VAS tends to defragment and the contiguous space starts to fall and if the TS2014 editor cannot load into the VAS by NOT having enough contiguous space to load into (and this can be as little as 1MB that TS2014 needs) and a SBHH will follow.

Note: Not all SBHH's when editing (or running) TS2014 are due to VAS issues. If the editor is not easy to use you can inadvertently instruct TS2014 to make an "illegal memory call", This could that the code is still in the VAS and the OS has not passed it to the cpu and into the working set in the RAM - SBHH will follow.

There is a registry hack that can help the VAS from defragmenting (in a 32-bit OS only so far as I know) and the reference is here http://support.microsoft.com/kb/315407 its called by its short name "HeapDecommitFreeBlockThreshold" registry key. It was used for Windows server editions but I used to use it in Win XP 32-bit before I moved to a 64-bit OS.

I'm sorry this is technical but if you can understand the concept of the VAS you can see why you get SBHH errors that are nothing to with the amount of Physical RAM + Paging file installed. The VAS is part of the Operating System and the RAM is part of the hardware two totally different things.

Axe if you don't understand this you don't understand how TS2016 works and how you can stop it crashing!!

[Axe]

Originally posted by Phase3:

...Axe if you don't understand this you don't understand how TS2016 works and how you can stop it crashing!!

Luckily I don't pretend to, and never will. The game is fine for me...

I'm more of your sound engineer, web designer, guitar playing published writer and proof-writing type...