Train Simulator Classic – Developer Update Part 2

Hello again, everyone! As promised, I’m here with an update on our current progress and, given the previous article has raised all kinds of questions, theories, wishes, desires, and concerns, I wanted to get a start on delving deeper into the detail and help answer questions and hopefully overcome any concerns.

If you missed the last developer update you can read it here.

Before I get to our current progress, I thought it would be helpful for you to understand how we’re going about the work on improving the core. We’ve essentially taken our overall vision of the software and broken it up into bite-size manageable chunks. Each chunk represents a sprint of work, with a short testing pass to make sure we’ve not broken anything, and possibly one or more alpha builds that we give to our testers to do the things we can’t do in a clinical development environment such as just play the software. We call these Phases.

Phase 1 is almost entirely about cleaning up the code, removing redundant or unused elements, and upgrading key plugins (dependent applications such as Silverlining, OpenAl, PhysX, etc) all of this with an aim to upgrade to a newer version of Visual Studio (the software we use to compile our code into something you can use). Newer versions of Visual Studio provide better compilers, better debugging tools (finding bugs) and better profiling tools (making more efficient code). At the start of the project, we were on Visual Studio 2010 (VS2010).

Unfortunately, when working with a codebase as complex as Train Simulator’s, you cannot simply just go from VS2010 to the latest version of VS2022 because you run the risk of corrupting the code. It must be upgraded progressively so we can ensure each version is clean before progressing up to the next – and by clean, I mean that we need to clear out all the warnings and errors that are being flagged by the previous version before progressing up to the next. There are also some limitations in that some of the 3rd party plugins that Train Simulator relies on cannot be compiled past a certain version of Visual Studio (Scaleform is a classic example of one that cannot since it was deprecated a while ago). So, we need to take it one step at a time or one major version at a time, the major versions being VS2010 > VS2013 > VS2015 > VS2017 > VS2022.

At the time of writing, we are now on VS2017 and this has revealed a ton of new errors and warnings that were not present under VS2015. This is to be expected and indicative of upgrades in coding practices, better ways of handling things, etc. we believe the rough number of errors were in the region of a few thousand which all needed to be tidied up and quashed.

We have removed almost all redundant code and stripped out almost all redundant plugins, the only ones that remain have deeper integration in the code that require substantially more time to unpick and may have some function somewhere that is currently unknown. All relevant plugins such as OpenAl, Silverlining, etc. are now all running under VS2017. We are now working on the final Visual Studio upgrade to VS2022 ready for implementing the DirectX12 translation.

So, you may be asking why all of this is necessary? Well, it’s quite important that before we can build on to the code and make improvements, we need to have a solid foundation that we can build on top of. The work we’ve done up to now is all about making sure that any possibility of instability has been minimised as much as possible.

One thing we have found with the work we have done so far is that the software is much more stable than the version you are using right now. Though we will wait to celebrate that achievement until you all have had an opportunity to try it out.

Before we move on to the final (exciting) part of this Phase, we’re changing how the software reports problems to you with much more information on what it was doing at the time it ran into a problem. This means the dreaded “Out of Memory” error will go away forever! It also means it should be easier to determine what caused the problem whether it was a problem with the content you were trying to load or something else that needs to be reported to our Customer Support. Once this is completed, we will then need to test where we are, so that means preparing a build ready for our internal testers to try to break. This aspect is essential because we will need to clear out any bugs before we continue forward as the 32-bit edition will become the build that will see no further updates. Our work beyond this will be entirely on 64-bit since that is where modern PCs are at.

Our next step will be to begin implementing the DirectX12 translation tool. At this stage we don’t have any idea what this is going to entail, or even if it will work but, we’re going to give it a go and see where it takes us. I’m sure you will all be excited to hear about any news on this and we will be back as soon as possible to update you. For the time being, the DirectX 12 translation will remain an experimental feature and live separately from the main build. You will therefore need to opt into it when it becomes available. There’s a good reason for this in that we simply do not have the resources to test everything out there so we will need your help in uncovering any undesirable effects.

So that’s pretty much where we are right now. We’re keen for you to keep your questions coming, so please do keep sending them through. We appreciate that not a lot of what I’m saying here is going to make much sense so if we can help clarify things, please do let us know.

It’s good to see that we all have our own ideas on what ‘improvement’ means to us individually, one question and topic I’ve seen come up several times is whether things like the Consist Editor will get fixed any time soon.

The short answer is, it is entirely likely to see some form of improvement as we move forward – soon is a relative term that can mean anything. If you’re expecting it next week, then the answer there will be no. However, if you mean at some point in the next year, then the answer is likely to be possible but depends on several other factors.

The long answer is, from our perspective, there’s nothing wrong with the Consist Editor though we know that it causes frustration everywhere, particularly for those that use repaints (reskins) or have vast content libraries which it was never designed to handle. We know that if you have a lot of content that it can be particularly slow cataloguing your collection and you have to go through this process every time you use it – which is not great. In Phase 2, we will begin our work on the content management system and, as this feeds directly into the Consist Editor, it is entirely likely to bring some benefits. First, though, we need to understand from your perspective where the Consist Editor is failing to meet your expectations, so we can factor this into our thinking as we’re working on it. Getting a clear understanding of why you feel it doesn’t work, as well as how you feel it should work will be invaluable information for us.

We know one major area that people have been concerned about is that as we upgrade the core it is likely to break some content. It is a perfectly valid concern.

We have always been particularly proud that we’ve been able to get this far whilst maintaining compatibility with about 95% of the back catalogue of everything people have made over the last decade or more. It is something we continue to think about, and we can assure you it remains firmly in focus as we move forward. Backward compatibility has always been a controversial subject and it is the main reason why we have held off on making any sweeping changes due to fears of breaking things. However, we have reached an impasse with TSC that means if we do nothing, it is likely you will no longer be able to use it at all in the not-too-distant future. This work is therefore important to ensure you can continue to use your content forever.

We would like to guarantee that we will always have backward compatibility, but the truth is, we don’t have all the answers yet. Some things we will need to trial first before we can answer those kinds of questions. We have an ambitious plan and there are things we want to achieve but it is entirely likely that we will reach a point where we will have to make a difficult decision on how to move forward. We hope we can come to you all at that time and get your views on how you think we should proceed.

Some things we know outright that are going to impact backward compatibility and are areas we are currently not looking at, are things like Physically-Based Rendering (aka PBR) and a hardcoded DirectX version upgrade (non-translation). We know these will fundamentally break everything in the back catalogue and is likely to impact the workflow for everyone who makes content for Train Simulator making it much harder for people to make content.

Backward Compatibility is important, and we do hear your concerns and we are actively working to ensure we try to maintain this as much as possible as we move forward. There may be one or two things that may warrant attention as we go but we will look at those on a case-by-case basis.

There are also things we are learning as we go. For example, we have just learned that we may run into problems with LUA and our aim to upgrade the current version to the latest one. It appears that there are a lot of changes in LUA between versions and it may not be achievable without breaking everything. So, this may be one of those things that we cannot change to preserve backward compatibility. However, we intend to still investigate options when we get there and we will, of course, let you know what the outcome of our investigation is.

We know that performance of core is perhaps one of the most important aspects of the software as it stands today – this definitely comes across as something you’re most concerned about in all the feedback we’ve seen to-date. So, we are looking to prioritise this in the next phase of development and move us a step closer to providing better support for multi-core processors. At the moment, we don’t know what this will entail but we feel this will unlock a great deal of potential in the software for everyone, so, it’s worth pursuing as a priority.

Finally, before we sign off, we just want to re-iterate that if you want to utilise DirectX 12 in our upcoming experimental build, you will need to be using a 64-bit version of Windows 10 or 11. Unfortunately, DirectX 12 is a Windows 10 and 11 only feature and is not supported for Windows 7 or 8. This is entirely outside of our control.

If you have any feedback or questions on anything in here, or the previous developer article, you can post in the forum thread linked below. Keep an eye on Dovetail Live and our social channels for future updates.