Discussion: Zusi 3 long-term development

[btrs]

Hello,

I'm a first time poster here but have already been registered some years here on the forum and was actively following Zusi 3 developments. I'm also active in the MSTS/OpenRails-scene as "msts.be", so some might know me from there.
Now that Zusi 3 has gone (or at least tried to go) international with the Aerosoft/Steam edition I think it is also time to start a critical discussion on the long-term development plans for Zusi 3.

The first major issue that has to be handled ASAP is the poor language optimalisation/translation and (lack of) English documentation. Aerosoft has done a very sloppy job here, and I feel they should put more effort into this aspect of the sim if it wants to succeed over the Germanic language borders.

Other points/features I have serious questions about when and if they will ever see the daylight:

· Better and in the end complete optimalisation for Windows 10. We all know development of Z3 started in 2004 in the heyday of Windows XP 32-bit, and that that was the intended target platform (with a estimated release - at that time - in 2007). Around 2013 the demo was around, and in 2016 finally the full version was released, and we already were in the Windows 8.1 period, with Windows 10 1607 lurking around the corner.

I don't mean the sim should dump the classic Win32 interface and go for Metro/Fluent Design app design interface. Those wishing that can go to Train Sim World to fulfill their needs.

What I do mean is the following:

a) complete support for HiDPI and window scaling support. (i.e. DPI-font size settings > 72 dpi/higher than 100%) Microsoft has only gotten better at this since v1809 IMHO, when finally their native apps also started working properly under HiDPI.
I know Zusi 3 is in this stage of converting SD-cabviews to HD-cabviews, but this shouldn't stop the fact that at one point users want to run at higher resolutions. And yes, while the cabviews will be stretched out, the outside image will be at least in the screen's native resolution.

b) a full 64-bit version should also be on the roadmap. EEP has gone exclusively 64-bit since version 10 I think (correct me if I'm wrong, not completely aware with their developments), since 2019 there also is a (unstable) 64-bit TS2019 and soon openRails will go 64-bit as well by switching their engine toolkit from XNA to MonoGame.
Even with Zusi's modular route network in use today, this should help for even more detailed or AI-intensive routes as it can allocate more memory to the simulator instead of the 3.5 GB limit now.

c) With the introduction of a 64-bit version this also means letting go of legacy systems, in particular Windows XP and soon also Windows 7 and 8 (at least their 32-bit versions). Please correct me if I'm wrong, but it seems Zusi is programmed in pure Win32 C or C++ API (or does it also use .NET Framework) ?
In any case, Carsten should start to become familiar with new additions to the Win10 C++ API or newer .NET Framework versions (4.7 and 4.8 are still supported on Win 7, 5.0 which is in development will probably be not), and start implementing optimizations from those APIs.

d) That brings me to a next point which is also linked to point c, and that is multi-threading. AFAIK Zusi 3 prefers few but fast cores (high clock frequency), which means that there is only a single or maybe 2 threads that Zusi is able to use. Legacy MSTS is even worse, but it was introduced just before multi-core processors started to appear, so let's ignore this simulator.
OpenRails has basic multi-threading, but is still heavy CPU-bound like MSTS. It might improve once the switch to MonoGame offloads more work to the relevant parts (CPU/GPU/Network/...)

· Next major topic is the rolling stock library.
While I must congratulate the team in supplying such a variety of German rolling stock which is able to run on most historic and modern routes, there is one point that needs to be improved and that are the passenger coaches.

https://www.zusi.de/zusi-3-hobby/liefer ... wagen.html" target="_blank

I mean: come on, these window-less shells with basic bogies are good for a 2004 MSTS or openBVE level. Even Zusi 3 could use some graphic sparkle.
Also here I don't expect full-blown 20000+ poly monsters like the coaches from TS201x, but at least a basic interior and some nice touches (realistic "Zuglaufschilder" or Zugzielanzeige for n-Wagen/Dostos) would enhance the realism even more.

I know that the software core development is mostly a one-man show, aka Carsten himself. So he will probably be able to answer my more technical questions.
For the rolling stock questions I also hope to get more input from the relevant team and material builders themselves.

Für beide Subjekte könnt ihr auch in Deutsch antworten falls ihre Englishkenntnisse hier nicht ausreichen. Meine Deutschkenntnisse reichen zwar genügend aus zum Lesen, aber diesen ganzen Subjekt übersetzen werde mich viel mehr Mühe brauchen. Also habe ich Englisch gewählt um mich besser aus zu drucken können.

[F. Schn.]

The first major issue that has to be handled ASAP is the poor language optimalisation/translation and (lack of) English documentation. Aerosoft has done a very sloppy job here, and I feel they should put more effort into this aspect of the sim if it wants to succeed over the Germanic language borders.

You can open a topic and post translation errors. The docu is complete for everything except programmers and editors. But we are looking if volunteers can continue with the rest: viewtopic.php?f=76&t=15445" target="_blank

In case of a bad programe translation you can simply modify the \_InstSetup\language\English\text.txt file. You can also add Dutch or French trnslation. Please inform us on any errors.

a) complete support for HiDPI and window scaling support. (i.e. DPI-font size settings > 72 dpi/higher than 100%) Microsoft has only gotten better at this since v1809 IMHO, when finally their native apps also started working properly under HiDPI.
I know Zusi 3 is in this stage of converting SD-cabviews to HD-cabviews, but this shouldn't stop the fact that at one point users want to run at higher resolutions. And yes, while the cabviews will be stretched out, the outside image will be at least in the screen's native resolution.

As far as I know the middelware that is used to style the UI does not support this properly. Maybe on the long term a update for this component is possible, but see b)

b) a full 64-bit version should also be on the roadmap. EEP has gone exclusively 64-bit since version 10 I think (correct me if I'm wrong, not completely aware with their developments), since 2019 there also is a (unstable) 64-bit TS2019 and soon openRails will go 64-bit as well by switching their engine toolkit from XNA to MonoGame.
Even with Zusi's modular route network in use today, this should help for even more detailed or AI-intensive routes as it can allocate more memory to the simulator instead of the 3.5 GB limit now.

Sorry, but you overestimate the advantage of x64. In general it may be possible. Zusi is programmed in an old Delphi version. It is possible to update to a current Delphi version but according to other programmers this is a massive amount of time. The advantage is nearly nothing. If Zusi does not require more than 2 GB address space it only profits of new compiler optimizing techniques. In contrast EEP has a bad programme structure that waste permanently memory. So x64 was a clear step here.

c) With the introduction of a 64-bit version this also means letting go of legacy systems, in particular Windows XP and soon also Windows 7 and 8 (at least their 32-bit versions). Please correct me if I'm wrong, but it seems Zusi is programmed in pure Win32 C or C++ API (or does it also use .NET Framework) ?
In any case, Carsten should start to become familiar with new additions to the Win10 C++ API or newer .NET Framework versions (4.7 and 4.8 are still supported on Win 7, 5.0 which is in development will probably be not), and start implementing optimizations from those APIs.

Zusi is programmed in Delphi. I'm sorry but no. C++ std libs are aviable for older systems and change the design to fit new classes is not a good effort balance.

d) That brings me to a next point which is also linked to point c, and that is multi-threading. AFAIK Zusi 3 prefers few but fast cores (high clock frequency), which means that there is only a single or maybe 2 threads that Zusi is able to use. Legacy MSTS is even worse, but it was introduced just before multi-core processors started to appear, so let's ignore this simulator.
OpenRails has basic multi-threading, but is still heavy CPU-bound like MSTS. It might improve once the switch to MonoGame offloads more work to the relevant parts (CPU/GPU/Network/...)

Mult threading sounds like a buzzword here. Zusi already makes use of multi threading with a seperate loading task. The problem is that the drawing process cannot really take advantage of muliple threads. Other tasks like the physic engine could be seperated in another thread but at the moment there is no need for that due to less time consumption.

What you did not mention is DirectX9. In fact this is a component that may increase performance a little. But this would be a much higher effort than switching the Delphi version an in fact rebuilding the graphic core. I don't thik its worth it.

While I must congratulate the team in supplying such a variety of German rolling stock which is able to run on most historic and modern routes, there is one point that needs to be improved and that are the passenger coaches.

Okay, this must not be done by Carsten. But I think the mayority of the modell builders do not see any neseccarity. I don't miss interior on such mall windows that are only passed side by side. Zuglaufschilder will almost always be wrong. It would be a kind of black hole if you implement them without implementing a programme that generates a dynamic texture that is sourced by the train file. The same applies to Zugzielanzeige, the current Zugzielanzeige often contains wrong content so after lots of critics we came to the conclusion to switch them off.

There is another problem you missed: We are lacking a verry large number of coaches. Locomotives are okay, but long distance passenger coaches and modern fright coaches have really big holes and wo often need to replaye them by others. I expect the community will prefer to focus on that. And I did not even mention other countrys.

And for the core programm there is a even wider range of important feature wishes that will almoast certainly will be prefered by the community: Modern Diesel locomotives do not work yet. Steam locomotives do not work yet. Railway crossings do not work properly yet. ETCS L1 LS does not work yet. Crocodile does not work yet. Multiplyayer either with signal boxes or different drivers do not work yet. And one of the most important: shunting does not work yet, on sight does not work yet, train (un)couple does not work yet. I think we want to focus more on that.

[Jan]

If Zusi does not require more than 2 GB address space it only profits of new compiler optimizing techniques. In contrast EEP has a bad programme structure that waste permanently memory. So x64 was a clear step here.

Correction: That should be "If Zusi does not require more than 4 GB address space." We already know that some of the more complex areas (Kassel, Hagen) exceed the 2 GB barrier (especially if increasing the drawing distance somewhat beyond the default value, but possibly even with the default settings) and indeed there was much rejoicing when Zusi was finally made LARGEADRESSAWARE and therefore able to use 4 GB of address space on 64-bit operating systems (also the new memory manager is supposedly more efficient regarding address space fragmentation, so the effectively usable memory in fact more than doubled).
It remains to be seen whether even more complex future routes might one day push memory requirements beyond 4 GB, too, but until that is the case I'd agree that there are other more urgently missing features than a 64-bit conversion.

[johannes4321]

I'm quite certain that a modern toolset making use of modern CPU features (vectorisation with SSE instructions etc.) can speed up calculations by a lot. 64bit might play a role (more registers, more efficient calling conventions making use of them) but updating tooling certainly is a big effort (no idea how Zusi is architectured, how well new logic can be put in dlls to modernize bit by bit etc.) so given constraints on available developers is questionable place for effort (while old tooling causes more problems over time and migrating later costs more ... and my heart screams "open source" as professional users would certainly require additional services ... but whole other debate)

Back to topic:

There is another problem you missed: We are lacking a verry large number of coaches. Locomotives are okay, but long distance passenger coaches and modern fright coaches have really big holes and wo often need to replaye them by others. I expect the community will prefer to focus on that. And I did not even mention other countrys.

And for the core programm there is a even wider range of important feature wishes that will almoast certainly will be prefered by the community: Modern Diesel locomotives do not work yet. Steam locomotives do not work yet. Railway crossings do not work properly yet. ETCS L1 LS does not work yet. Crocodile does not work yet. Multiplyayer either with signal boxes or different drivers do not work yet. And one of the most important: shunting does not work yet, on sight does not work yet, train (un)couple does not work yet. I think we want to focus more on that.

This seems like a way better and relevant TODO for a short to midterm period.

One thing I'd wish to add is "usability for average users" finding trains/routes is hard currently. Providing maps and search features shouldn't be too hard and greatly improves the quality of life. My ZusiLauncher is a result of desperation of trying to find "interesting" rides (engine being used, playing time etc. as factors) such a thing integrated with a cache of the "database" (reparsing XML and eventually rerendering previews of trains etc. takes time while it's mostly static information. I have a prototype for ZL doing some cache serialisation and refreshing, making startup with searchable index a matter of a few moments) could make Zusi a lot more attractive (while learning curve of actual driving the train, understanding signaling etc. will still be there - an advanced "Schunmelinfo" could help with understanding signaling and train control ...) to casual users. (I seriously don't know Zusi's data structures/data files and don't know a lot about UIs and Windows, as I create databases and programming languages for a living and and do ZL to gather some experience and and more or less subtle try to spin up ideas what could be done, by somebody more in that field)

[F. Schn.]

I don't think so. Carsten some kind of... er... well, I don't want to say "failed" but it gets in this direction ... with a file hash algorithm. And I don't wonder that; it simply takes time to find out how to best do this. MrX did some investigation and set up a high performant tool. But I guess it takes time and rescources to think into the problem. And a database based starter is much the same. It simply can be outsourced verry easily. So I think you and Holger did a good job. Maybe Carsten should rather think about install and update thirdparty programes like ZusiMeter and one of your starters with Zusi - like ZusiDisplay does at the moment. The interfacs between your programe and Zusi itself is small and already available. This is not the case for steam (at the moment works with workarounds only and Zusi Fzg Editor is missing completly yet). And for the rest of the list its even impossible.

[johannes4321]

Ack.

When I wrote the above I was also thinking about a different tool (ZusiStart, ZusiLauncher, something new whatever ...) being official part of the Zusi system and embedding the simulator conceptually similar to ZusiDisplay integration and leaving current UI for "expert users" similar to me saying to use modern tooling for feature dlls etc.

Anyways, my insights in the constraints (technical, business, ...) is limited to say the least and a debate which probably is off-topic in this thread. So probably last of me here