Forcing Trainz to Use Ram

R

Rougespear7mm

Canadian DEM Provider
Just a simple thought from me while I was musing... If I recall correctly, Trainz will only make use of 2GB of RAM and a total of 2.5GB is optimal; anything more than 2.5GB is just a waste when it comes to Trainz!

Is there a way to force Trainz to use more than 2Gb of RAM? Some sort of scripting or something? I think that a limit of 2GB may end up being "the" bottleneck on some systems. Would the use of larger amouts of RAM by the game prove to allow use to run more complex routes?

Just musing... thoughts are welcomed:)
 
Maybe that extra .5 GB RAM is for, I think, safety reasons, although I'm not too experienced in the game, there has to be a reason for it to only use 2 Gigs. But I'm listening to anyone too, since mi ordenador no desea cargar Saginaw Sub demasiado bien ...
:wave:

Joshua
 
First the 512 mb of memory is for the operating system.

Second if you have a 64 bit operating system then programs under its control can make use of 4 gigs of memory providing they tell the operating system they can use more than 2 gigs.

Technically you can run a small program that alters the values in a couple of locations of the Trainz program so that it indicates the the operating system that it is one of these programs.

If you going digging on the Microsoft site there are more details.

Or Auran can simply recompile the program so that it can use 4 gigs of memory under a 64 bit operating system.

There are some dangers as not all programmers program nicely. Occasionally one will decide to use the top bit on the address line which is never used for anything with the 2gig limit to store a value. If they have then the program falls apart. Remember its if any programmer who has ever worked on the software has used this trick then Trainz will not work correctly in 4 gigs.

Also Trainz uses tables to keep things in memory, the indexes need to be large enough to address the full size of the table and going through the code looking for these things to increase their size is not terribly nice work.

Cheerio John
 
johnwhelan said:
Trainz is also limited to 2 gigs in 64 bit Windows unless you alter the Trainz executable.

Cheerio John
Click to expand...

It would actually need to be ported to Win64 (which means Auran would have to maintain two different installers - one for x86 (32 bit) and one for x64 (64 bit).

How difficult the port itself is depends a great deal on the nature of the code. If the code was written with a future 64 bit version in mind, it may well be straightforward (modern compilers such as Visual C++ 2008 will automatically warn when they detect code which is not likely to be 64 bit compatible) but it is unlikely to be trivial, and would of course require significant testing.

Is it worth it? That's a call only Auran can make, really

Oops! I think I've just given my day job away...:o
 
johnwhelan,

Do you have any more information about this "small program that alters the values in a couple of locations of the Trainz program so that it indicates to the operating system that it is one of these programs"? I'm curious to see if I could get something like that running in the background and see if it would make a difference in Trainz's performance...

Thanks, Brent
 
Rougespear7mm said:
johnwhelan,

Do you have any more information about this "small program that alters the values in a couple of locations of the Trainz program so that it indicates to the operating system that it is one of these programs"? I'm curious to see if I could get something like that running in the background and see if it would make a difference in Trainz's performance...

Thanks, Brent
Click to expand...

Try digging in Tomshardware.com and anandtech.com there is a discussion in there the software is part of Microsoft's tools. Or search this forum for posts that contain cheerio and 4 gig limit, I think I posted this somewhere.

Cheerio John
 
durhamlass said:
It would actually need to be ported to Win64 (which means Auran would have to maintain two different installers - one for x86 (32 bit) and one for x64 (64 bit).

How difficult the port itself is depends a great deal on the nature of the code. If the code was written with a future 64 bit version in mind, it may well be straightforward (modern compilers such as Visual C++ 2008 will automatically warn when they detect code which is not likely to be 64 bit compatible) but it is unlikely to be trivial, and would of course require significant testing.

Is it worth it? That's a call only Auran can make, really

Oops! I think I've just given my day job away...:o
Click to expand...

This would be the nice way but I've seen a write up saying it is technically possible to take the 32 bit executable and let it address 4 gigs. I don't have a 64 bit operating system at the moment so I'll let some one else try it first.

Cheerio John
 
32 bit apps under Windows x64 run within a "compatibility box" which insulates them from the raw 64 bit API, so whilst it is probably technically possible to modify the header of the file to trick Windows into thinking it's a 64 bit PE image, it won't necessarily run as one - 64 bit PE images use a different API and CPU instruction set to their 32 bit counterparts, so odd behaviour and random crashes are the most likely result.

It really does depend on how much of the APIs it uses, of course. You may just get away with it, of course...
 
Last edited:
durhamlass said:
32 bit apps under Windows x64 run within a "compatibility box" which insulates them from the raw 64 bit API, so whilst it is probably technically possible to modify the header of the file to trick Windows into thinking it's a 64 bit PE image, it won't necessarily run as one - 64 bit PE images use a different API and CPU instruction set to their 32 bit counterparts, so odd behaviour and random crashes are the most likely result.

It really does depend on how much of the APIs it uses, of course. You may just get away with it, of course...
Click to expand...

Ok let's go heavy. Each "word" or instruction consists of a few bits that are the instruction then some address bits plus a few modification bits. The limitation in Windows basically restricts the instruction from accessing any location which is out of bounds. So a program instruction maybe capable of addressing 4 gigs of locations but is restricted by the operating system down to 2 gigs. The number of bits allowed for addresses is for the most part 32 bits which allows access to the magic 4 gigs of memory.

So we have two limitations one the address limitation in the instruction, the other the op system out of bounds. 1 bit gives two possible addresses, 2 bits gives 4 possible addresses, 3 bits gives 8 possible addresses etc upto 32 bits which gives the magic 4 gigs address limit. To go over this limit I need to use instructions with a bigger address space or different instructions. These are the 64 bit additional instructions.

However the 2 gig limit is actually due to an internal windows limit in 32 bit windows, this limit doesn't exist in 64 bit Windows. So when the program starts it can tell 64 bit windows it is a 32 bit program running to a max of 2 gigs or a 32 bit program running to 4 gigs or a 64 bit program.

Cheerio John
 
johnwhelan said:
Ok let's go heavy.... Each "word" or instruction consists of a few bits that are the instruction then some address bits plus a few modification bits. The limitation in Windows basically restricts the instruction from accessing any location which is out of bounds. So a program instruction maybe capable of addressing 4 gigs of locations but is restricted by the operating system down to 2 gigs. The number of bits allowed for addresses is for the most part 32 bits which allows access to the magic 4 gigs of memory.

So we have two limitations one the address limitation in the instruction, the other the op system out of bounds. 1 bit gives two possible addresses, 2 bits gives 4 possible addresses, 3 bits gives 8 possible addresses etc upto 32 bits which gives the magic 4 gigs address limit. To go over this limit I need to use instructions with a bigger address space or different instructions. These are the 64 bit additional instructions.

However the 2 gig limit is actually due to an internal windows limit in 32 bit windows, this limit doesn't exist in 64 bit Windows. So when the program starts it can tell 64 bit windows it is a 32 bit program running to a max of 2 gigs or a 32 bit program running to 4 gigs or a 64 bit program.

Cheerio John
Click to expand...

Heavy? Nah - this is just light relief. :p

Notwithstanding the API differences, an Intel/AMD CPU running as x64 is a somewhat different beast to the old x86 variety - not only is the memory management different, but the CPU instruction set too (although they do have a common subset). As a result, machine code which will work fine in x86 is illegal in x64 mode and vice versa.

It's a potentially very nasty minefield. But as I said, you may just get lucky...
 
johnwhelan said:
Try digging in Tomshardware.com and anandtech.com there is a discussion in there the software is part of Microsoft's tools. Or search this forum for posts that contain cheerio and 4 gig limit, I think I posted this somewhere.

Cheerio John
Click to expand...

There is an interesting article at Tomshardware about 64 bit Gaming and how to improve 32bit gaming http://www.tomshardware.co.uk/64-bit-vista-gaming,review-31535.html was this what you were thinking about John?

Regards,

Tony
 
trainmetal said:
There is an interesting article at Tomshardware about 64 bit Gaming and how to improve 32bit gaming http://www.tomshardware.co.uk/64-bit-vista-gaming,review-31535.html was this what you were thinking about John?
Click to expand...

Hi Tony,

Thanks for posting that. The linked article clarifies the confusion - it discusses patching a 32 bit PE image to set a linker option which gives it access to 4GB RAM rather than 2GB. It wil still be a 32 bit app, so there shouldn't be any API problems etc.

By comparison a true 64 bit app can theoretically access 8TB of RAM (not that I've ever seen a machine with anywhere near that much!).
 
I used XP 64 bit with TRS2006 and noticed no difference in performance.
Drivers were a problem at the time as well. Therfore I reverted back to 32 bit Windows.

Computer mags fundis said that a 32 bit application running under wow emulation sufferred from converting 64 bit system files to 32 bit caused a decrease in performance.
 
trainmetal said:
There is an interesting article at Tomshardware about 64 bit Gaming and how to improve 32bit gaming http://www.tomshardware.co.uk/64-bit-vista-gaming,review-31535.html was this what you were thinking about John?

Regards,

Tony
Click to expand...

Thanks that was the one that came to mind. It also discusses the trade offs but in Trainz case because I suspect it uses tables in memory that expand based on the size of layout and the rolling stock on it you might get a little more benefit speed wise I'd be uncertain about stability.

Anyone want to try?

Cheerio John
 
just to sum, and a question...

just to sum, this is from a comment on that article:

"Like the article stated moving to win64 isn't going to be faster. Once games start to use the extra memory there will be a qualitative difference in the gameplay. For example the extra foliage on the win64 FarCry."

so, it looks like a 64bit environment would make a richer world possible -- and the article mentions that the crysis team moved to 64bit because the had more things to add to the 'look' of the game than 32bit was allowing, yes? and that it's not about giving a 'no stuttering' scenario for us, unless, as is said, there's some rewriting of the the application to cause less harddrive churning? that 64bit can allow something like that?


johnwhelan said:
Thanks that was the one that came to mind. It also discusses the trade offs but in Trainz case because I suspect it uses tables in memory that expand based on the size of layout and the rolling stock on it you might get a little more benefit speed wise I'd be uncertain about stability.

Anyone want to try?

Cheerio John
Click to expand...
 
mikemike said:
just to sum, this is from a comment on that article:

"Like the article stated moving to win64 isn't going to be faster. Once games start to use the extra memory there will be a qualitative difference in the gameplay. For example the extra foliage on the win64 FarCry."

so, it looks like a 64bit environment would make a richer world possible -- and the article mentions that the crysis team moved to 64bit because the had more things to add to the 'look' of the game than 32bit was allowing, yes? and that it's not about giving a 'no stuttering' scenario for us, unless, as is said, there's some rewriting of the the application to cause less harddrive churning? that 64bit can allow something like that?
Click to expand...

Normal games control what is in shot to keep it within certain limits such as the maximum amount of memory available on the machine. Trainz is open ended and the person creating the scene often does not take into account such things. There will almost certainly be multiple dynamic tables in the game and if you add them all up then they must not exceed the maximum memory. So a guess would be unlike most closed system games it is possible that Trainz maybe able to take advantage of going to 4 gigs max which would still use the existing 32 bit code.

No stuttering is possible today with very fast hard drives such as the solid state disks that are now available. Also having 2.5 gigs of memory helps memory access is in nanoseconds, disks in milliseconds or 10,000 times slower. It also helps to have a fast cpu quad with TRS2009, and a fast graphic card with good drivers that can off load the cpu.

Cheerio John
 
You must log in or register to reply here.

Similar threads

A
Looking for advice to rebuild my PC.
2
Replies
20
Views
1K
johnwhelan
J
J
GPUs and getting power to them.
Replies
10
Views
1K
turntable
T
R
New PC build for Trainz Etc. FINALLY finished
Replies
4
Views
518
ricomon35
R
P
GeoForce NSW app and Trainz
Replies
0
Views
359
PhilChorusch01
P
E
Has anyone tried to stream Trainz from a Windows host to a Mac?
Replies
6
Views
185
ricomon35
R
Back
Top