I agree with you on the ECC RAM. If you remember, we all had RAM with parity. Then manufacturers got cheap, they ditched the parity row and developed ECC RAM for workstations and servers only.On Linux for me Trainz actually performs better. Windows biggest problem has been excessive bloat which has been an issue since Windows 1.0.
We should also consider that hardly anyone uses ECC RAM, and we all should be. You can pump a ton of RAM into your computer but it will always fail, because it can't self repair. Linus Torvalds recently mentioned this at PC Gamer recently. Why this matters is performance isn't one thing it's multiple.
Do we need 10K computers just to play trains at low settings? Maybe N3Vs choice of game engine when it was changed in T:ANE was a bad one. Unity might have been better, just look at Railroader and Derail Valley. Far and away better performing games with a tiny dev team.
I don't think any of us will ever get the answers that make sense. Trainz is virtual model railroading. If it does one thing right it's that.
We expect far too much in a game that isn't high bar. None of the HD or PBR textures should have been added until the game itself was not killing drives or GPUs.
20 years ago I graduated from college with a degree in Network Admin. All that has changed is our demands and unrealistic ones at that.
It may very well be bloatware, but I'm thinking it's Microsoft's Smartscreen that's doing it or is contributing to it. I noticed yesterday that Smartscreen kicks in when TRS-Plus starts up and I wonder if this is scanning and chunking away at the program.
The excessive writes though are a different story. I mentioned this back in TS12 days. The disk was constantly thrashing every time I loaded up a route or did anything with the program. At the time, I thought it had something to do with caching, which I still think is next to none. I'm not talking about the precaching of content to a file, yet again disk access, I'm talking about memory caching because the program acts as though it ignores the RAM and constantly loads off the hard disk then flushes again with constant writes.
During my test yesterday with Process Explorer, the content read rate was about two to three times what the writes were while I opened and edited my large route. This was constant throughout the test with a maximum of 760K reads and 256K writes with this being a count and not bytes or megabytes.
N3V developed their own game-engine inhouse. At the time, when TANE came out, Unity wasn't exactly a great performer, and the newer Unreal Engine was just showing up on the scene. They also said that these other prebuilt game engines didn't allow them to import older content or support what they needed. I think it was also cost due to the licensing.
In many ways, I agree that this homebrew wasn't a good move. While I enjoy running old routes I developed in the past, they should've gone all guns in and gone forward with a modern game engine.
In the past, I ran some Solaris machines at work including a SPARC server and I had a Sun setup at home with a few retired SPARCs I got from Polaroid when they were retiring the old SPARC 10s and an Ultra 5. The hardware really was spectacular and never failed unlike the PCs running Windows. I have looked into running Linux on my PCs. The problem is software support. I do some music editing with software that is not available with Linux support at least right now. Setting up yet another box or dual booting will make yet another thing to do just to play a game.
Last edited: