View Full Version : Trainz freezing

October 19th, 2016, 04:10 PM
I'm posting this question in the general section rather than the TS12010-specific forum because I suspect the problem and answers apply across most of the Trainz versions.

I took the laptop along to the model railway club night to give them a demo of the line I have been modelling. At home I work on the laptop with it hooked up to a TV giving me a 1920 x 1200 display. At the club, their giant TV turned out to only be 1300x768, so I tweaked the display width and height in the options file and ran the route. In driver I was getting a lot of freeze moments, up to 30 seconds duration, during which I had no keyboard control, no visual updates, just the sounds continuing. I am used to these freezes whilst building in Surveyor at home, but don't usually notice them in Driver. I assume they're autosaves by Surveyor.

Was the reduced display size somehow responsible for the freezing? They seemed to occur when I swung the cab or follow camera around, which made me suspect this was a draw-distance issue?

Are there any things I can do to reduce freezing to an absolute minimum? I was hoping to have a large screen display up at their next exhibition and run the route, but I don't think it would meet expectations if it had as many freezes as I got that evening.

I had run the sessions at home before setting out, so I was hoping the cache files would have already had the route in. I am now wondering if changing the display settings had somehow caused those cache files to become invalid and if I had persevered at the club I would eventually have got smooth running.

Spec-wise, by the way, it's a Medion Erazor X6811 laptop which works very well at home, so I don't see this as a machine-not-up-to-it issue, although it could also have been a graphics problem caused by running at a non-native resolution.

October 19th, 2016, 05:56 PM
This could very well be caused by the change in refresh rate. V-sync maybe the culprit in this case.

The other problem could be the game somehow ended up switching to Open/GL when you changed resolution. That can definitely cause awful performance problems if your system as an ATI (AMD) video chip on its motherboard.

Outside of that, I'm at a loss as to what to do.

Could you post the complete specs of your laptop? It helps (sometimes) with stuff like this.

October 20th, 2016, 01:08 PM
Had to dig into system manager,

Intel Core i7, 6.0Gb Ram, NVidia GForce GTX 460M with 1.5G Ram, Windows7 64-bit

October 20th, 2016, 02:34 PM

Upon looking at the video card, it may very well be that the display resolution might be beyond what your card can handle and still perform well. I recommend running at a lower resolution to achieve the best performance rather than overdriving the display.

October 20th, 2016, 04:20 PM
I'm a bit puzzled by that, the laptop has a native screen resolution of 1920 x 1200 which it handles perfectly well, surely asking it to drive 1300x768 is going to be the opppsite of overdriving?

I've been having a look at other routes, and my thoughts now are towards the UTM tiles from TransDEM which I have in my route, they're big objects (baseboard-sized) with some 512x512 textures on them, I'm wondering if the task of clipping parts of those ( admittedly hidden) objects to fit the viewport might be giving the program a bit of a hard task. And the smaller the display size, the more clipping it has to do?

October 20th, 2016, 07:19 PM
I am puzzled too, but that 1300 x 768 is not a native to the display card and the refresh is probably different if it is a TV and not a computer monitor. This will have the same effect as running at a resolution higher than the video card can handle, and will cause a lower performance. It's most likely related to the vertical sync.

I ran into this kind of situation with a work-related system. The laptop was configured to run a looped presentation out to a monitor. The performance was horrid on machine to begin with and when the machine was plugged into this big NEC monitor, it ran worse. As I was checking things out, the display was sensed as a generic PNP monitor instead of the NEC display it was supposed to be. I found the driver for the display on the web, installed it, and the performance was back to normal.

In addition to the above, I recommend switching your Trainz display mode from Direct X to Open/GL and back again. The reason for this is to force the game to update the caching. I noticed that when swapping from one display to another when using TS12 that this made the difference.

The Trainz draw distance is only 2000 meters in Driver and up to 5000 meters in Surveyor in TS2010. This has to do with the ability of the software drivers written at that time by NVidia and AMD. Since that time, we can now support up to 15000 meters, however, you'll never have to worry about that distance with what you are using.

Sure chopping out unwanted baseboards helps to a certain extent, but if they are unpopulated, there's no reason to waste your time doing so. The TransDEM textures are pretty light, load wise, and don't impact the system too much.