Train Simulator Classic – Developer Update Part 3

Now that our latest core is in your hands, and we have taken care of the most critical problems, we can begin to move forward with the next phase of work. Before we get into the details, we’d like to say thanks to the third-party developers who have worked closely with us to trace and fix the last remaining Lua issues. I’d also like to offer my personal thanks to Armstrong Powerhouse, Christrains, Smokebox, NZTSWS, Bossman Games and Virtual Railroads for their kind assistance in helping us test their content against our latest code fixes.

We know that there is still a subset of players out there who may still be seeing problems and we would encourage those to get in touch with Customer Support so we can continue to look at helping those players get back up and running. For now, we are seeing that core is more stable than it ever has been with a dramatic reduction in the volume of crashes being submitted to the server by 86%*. This can only get better as we move forward.

We appreciate that the last few weeks have been a bit rocky, and we are greatly appreciative of your patience and understanding whilst we have been working to tidy things up. The volume of players coming through to Customer Support and providing us with helpful details and data on problem areas has been amazing and we cannot thank you enough for all your support. The net benefit of your assistance has resulted in us being where we are today.

We’ll continue to work on bug fixes as we go but we wanted to outline our plans for Phase 2 with you.

From here on in we’ll be getting to work on our ambitious goal to improve overall performance of the software and that means FPS (frames per second). Before we get started, we have some administrative things to take care of, such as getting our build process sorted out to enable us to make builds easier (this is going to be important down the line) and look at how we retire 32-bit and how it’s going to work when we’re ready to do so. We’ll come back to you later when we have further details on this. Right now, nothing will change on your access to 32-bit. However, as an immediate change we’re looking to make, we’re going to switch the default start up option to 64-bit instead of 32-bit.

UPDATE: Please note that we have now changed the default startup options in Train Simulator so that the 64-bit Edition is at the top of the list. This does not affect your ability to select or play either 32-bit or 64-bit. If you have already saved a default option to play each time you load Train Simulator, you will need to reselect an option to save as your default option.

The first part of the improvement work we need to undertake is by updating our SilverLining plugin to the latest version. A great deal of work has gone into SilverLining since the version we’re using in core currently and much of that has been around improving performance and visuals. Naturally, this will have no tangible benefit to those who turn off 3D Skies and Dynamic Lighting but for those that do use it, there is likely to be a good improvement not only to how the skies and weather look but also how they render. We’ll know more about this once we’ve implemented it.

One of the takeaways from our recent core update is that you would prefer a beta to opt into as that way you have a fallback option in case the beta isn’t working. Whilst this was an option we investigated prior to the update; it was not an option we could pursue since the code changes prevented an overlap in versions. It would have made things far too complicated for us, and would have made things even more miserable for you, particularly in troubleshooting issues and tracing faults.

We do hear you though. Now that we have a good foundation in the code, we can absolutely do betas moving forward. So, once the SilverLining work has been completed, this will be your opportunity to opt into a Public Beta which will continue to be updated as we go. We will need your help in testing and tuning the plugin at each stage to ensure we’re getting the best performance out of it but also, we will need to tune the visual improvements so that it works with the rendering engine. The more feedback and perspectives we get on this will mean we all get something that not only works well but also looks fantastic too!

Once we’re ready for the Public Beta to start, we’ll let you all know how you can opt into it and where to post your feedback. We hope you’ll all want to get involved.

Whilst bug fixing is going to continue as we go, we want to start nailing some long-standing bugs like not being able to set graphics resolutions in-game for those using ultra-wide displays or for those that have so many graphics options that the list scrolls off the edge of the screen, and many more like them. I’m sure there’s something you can instantly think of that annoys you immensely every time you need to use it. This process is going to be on-going and is likely to go even beyond this phase of development. So, don’t be too concerned if the specific thing you’re hoping to get fixed isn’t fixed here. We may need to spend some time evaluating what we can and cannot fix and we will try to keep you updated as we go.

As we mentioned in previous articles, we have long been unhappy with the way TRAIN SIMULATOR works with content libraries. It takes a long time to deal with large content libraries, it doesn’t give the user any form of control and isn’t helpful when dealing with content that may be problematic. For us to improve how the software handles content, particularly large content libraries, we first need to understand how it manages content currently and where we need to make changes to improve how it works, so we’ll begin with an investigation phase where we will answer a lot of questions such as how it works and how do we want it to work? This will then form the basis of an implementation plan which will come later. At this point we will be looking to get your thoughts on how you feel it should work and where you feel the biggest problems are when you’re trying to find the content you want to play. We’ll set up a special forum for you to participate on this as we’ll need to give you some time to give it some thought and discuss ideas with other players. The best of these ideas will then be factored into the plan for implementation.

This is where things get exciting as we’ll begin looking into multithreading and seeing what our options are. Our goal here is to get TRAIN SIMULATOR working better with modern PCs and Graphics Cards. This work is going to be substantial and is likely to involve multiple builds where we will use your feedback to help us find the best performance. We will also be looking at whether we can offload CPU heavy tasks to the GPU to ease loads and look at supporting parallelism in those tasks.

We very much appreciate the feedback we’ve received so far on DirectX 12. We know that, from your feedback, that it has been largely hit or miss in terms of performance. Which is exactly what we were seeing in testing. Some players, because of their PC spec, were seeing better performance than others. However, largely, it seems to not be the silver bullet we were all hoping it to be.

We think the poor performance is a consequence of having to do double the work in translating DirectX 9 instructions to DirectX 12. This naturally places greater demand on your CPU and because we are thread limited in TRAIN SIMULATOR currently, it may be that there just isn’t enough performance overhead to do the DX upgrade in this way. We may see a different result as we explore multithreading, and this may unlock the true performance benefits of DirectX 12.

Later on, we also want to look at Vulkan since we know it’s DirectX 9 to Vulkan translation layer performs particularly well with very little work. This is likely to also improve substantially as we explore multithreading so, it may be the better option.

As you’re probably aware, there are some tools which fall outside of our plan to go pure 64-bit. The Blueprint Editor is one of those tools which we plan to upgrade to 64-bit. This includes a range of command line tools which are included in the TRAIN SIMULATOR installation folder, all of which are still constrained by 32-bit memory limits.

* Comparison of reduction recorded between a known 8-week period in 2020 and the same period in 2023