Atomic Systems

I keep getting an error when adding stock to a particular route about it being out of memory. That's a lod of balloni, with 11gig or RAM I'm doing fine, but I remember a previous conversation about TS2013 only using 4Gig. My question is can we speed it up in anyway, shape or formas it's rather cluncky, quite slow, and tells me I run out of memory everytime I get anywhere near Clapham Junction, for no reason, running the rL2B route fine at 33 FPS right the way back from Brighton with a fairly well sized amount of trains & stock along the route.

As TS2013 is a 32 bit application there is no way it can use more than 4GB of RAM. The only way to use more would be to build it as a 64 bit application, and only RS.com can do that.

How big is your kuju folder?

Drop your graphical settings right down and see what happens; if it loads and runs and you can add stock OK then nudge the graphics options back up till you find the point where the number of assets loaded makes it fall over. To possibly aid when editing a scenario, temporarily rename the routes scenery folder to prevent those assets loading.
Just out of interest, how much vRAM is fitted to your graphics card?

I have been experiencing similar issues with WLOS and occasionally Woodhead, I upgraded my graphics card recently and made sure it had 2gig vRAM but the same problems contined with out of memory errors, failed vertex buffering and crashing. I suspect we simply experiencing the limitations of what the core program in its current form is capable of, this means that the only people who could really solve this problem would be......RSC

What out of memory message? Because there are two memory times that can cause this. System ram, and Video ram.
What is the error message, how do you know it's a memory issue?

I suspect that it's not a real out of memory problem, but it's causes by a deeper error error in game.

Did you checked the system ram usage of RW in task manager, and the vram usage in another tool?

Allyourkitty, are you using 64bit windows?

32bit game = 4GB VAS.........stick a graphics card with 2GB vRAM in the equation and you immediately create the opportunity for the usable (by the game core) VAS to be halved.

Gary
Actually its slightly different:
32 bit OS running 32-bit App (TS2013) with Large Address Aware Flag set = 2GB VAS for kernel/system + 2GB for TS 2013 minus Working VRAM (can be limited to 512 MB blocks). (Both OS and TS2013 can only address a max 4GB Physical RAM)
64 bit OS running 32-bit App (TS2013) with Large Address Aware Flag set = all 4GB VAS for TS 2013 plus up to 8 terabytes for the Windows system. (TS2013 can address a max 4GB Physical RAM and the OS up to 192GB depending on version)

The VAS is not the same as Physical RAM and is independent of it - the VAS is part of the OS the RAM is part of the hardware. That's why even if you have 8GB Physical RAM installed if you run X-Plane ver 10.2 64-bit - then 8 terabytes of VAS are allocated to X-Plane and 8 Terabytes to the OS (Windows) ie 16 terabytes in all.

Having run extensive tests with VMMAP and TS 2013 I do not see any evidence on my rig (64-bit) that a SBHH error has anything to do with VAS depletion or fragmentation. The maximum VAS i have seen used is just over 2GB with little loss of contiguous space.

Regards
pH

Hi Peter, we still don't know whether he has 64 bit or 32 bit yet! - if 32 bit, Gary raised a very valid point - although I would have used `system` rather than `game` in the post.

There is also the small issue of what else is running on the rig?

.......and as VAS is comprised of both 'real' memory and hard drive space, is there enough free space on the disc?